АОТ для бизнес аналитиков

[George Nordic]

Понаписали-то сколько всего.

Вы путаете:
1. Причину и следствия.
2. Цель, процесс и результат
3. Источник знаний о бизнес-процессе.
и меня сильно запутали.

Итак.
Все дело в том, что нет методологии, о которой столько говорили большевики.

Предпроектное обследование.
Сначала делается анализ текущих бизнес-процессов компании, как есть - AsIs.
Потом владельцев бизнес-процессов спрашивают, а как они хотят их изменить с целью оптимизации бизнес-процессов. Если предполагается внедрение некой системы, идет демонстрация ее базовых возможностей (системы или решения).Анализируется, как внедрение данной системы повлияет на текущие бизнес-процессы, как они могут измениться. проводиться реинжиниринг бизнес процессов, рисуются бизнес-процессы, как они должны быть - ToBe.
Если планируется внедрение системы, то строится предварительный Дизайн решения - что должно быть в системе, если строить ее с учетом процессов, как они будут.
Данные документы фиксируются и подписываются владельцами бизнес-процессов и утверждаются спонсорами (кто будет платить за изменения). Более того, со спонсари утверждаются и Цели Проекта - что должно быть результатом реинжииринга БП или внедрения системы. Спонсоры могут внести изменения в список БП, в сами БП и Цели Проекта. Имея утвержденые Цели проекта и предполагаемые итоговые Бизнес -процессы, можно переходить к следующей стадии.

К сожалению, многие не понимают значимости фазы Анализа и отказываются за нее платить отдельно, или вовсе отказываются от детального предпроектного обследования, что зачастую мешает точной оценке объема проекта и его стоимости.
Проект
Дизайн. На фазе построения дизайна решения проводится анализ как мы можем сделать из того, что есть (AsIs) то, что будет (ToBe). Если предполагается использование системы автоматизации, то проводится Gap-Fit анализ: что уже есть, что нужно настроить, где необходимы доработки. На основании GF-анализа строится предварительный план проекта, в котором фиксируется оценочный обеъем, сроки внедрения и необходимые ресурсы, проект разбивается на этапы, строится архитетура решения. Обычно только на этой стадии можно с достаточной точностью сказать о сроках и объеме проекта. Дизайн решения обсуждается с владельцами БП и спонсорами.

После утверждения Дизайна решения начинается Разаработка: настройка необходимой функциональности, доработка системы или решения, тестирование доработок и настроек. Возможно, настраиваются роли пользователей и ведется их настройка. Результатом фазы Внедрения является готовая к Внедрению система, настроенная и доработанная в соответсвии с подписанным дизайном решения для работы по утвержденным бизнес-процессам. Результирующим этапом Разработки является тестирование, нагрузочное и интеграционное, с целью выявления ошибок, недоработок и оптимизации системы. Зачастую паралелльно с этим идет разработка пользовательской документации

Если все хорошо, и решение работает так, как было задуманно, но начинается этап Внедрения. На сервер ставится система, в нее заводяться пользователи, проверяются настройки безопасности. Заливаются настройки системы и основные справочники. Проходит обучение и тестирование пользователей. Итогом фазы Внедрения является работая система, готовая в эксплуатации, с обученными пользователями, которые готовы в ней работать. (Если без внедрения системы - то работать по новым правилам с соответствии с новыми БП и должностными инструкциями, но это отдельный разговор, сейчас о системе). Может начаться Опытная Эксплуатация системы.

Из старой системы вводятся начальные остатки и... начинается Опытно-Промышленная Эксплуатация. На этом этапе осуществяется "горячая" поддержка пользователей, которым все еще страшно работать в новой системе. Пользователи привыкают работать в новой среде. Обучаются новым возможностям. Найденные недочеты и нессответствия устраняются. Зачастую паралелльно с этим идет эксплуатация и старой системы на предприятии.

Когда пользователи привыкли к системе и могут работать в ней самостоятельно, Новая система работет не хуже старой, более оперативно и ведет учет как было запланированно (зачастую сравниваются операции в новой и старой системах, с анализом расхождений), работа на предприятии идет в соответствии с запланированными бизнес-процессам, а цели проекта достигнуты (желательно в срок и бюджет), то внедрение считается завершенным и начинается новая стадия - подержка.

Вот примерно так.

Вы же пытается идти от концепции "А что система принципиально может". Это в корне неверно.

С Уважением,
Георгий

[BOAL]

Цитата:

Сообщение от Evgeniy2020

через несколько поколений можно будет поговорить с ERP системой о жизни, и она выявит в жизни не совершенные бизнес процеса и предложит методы улучшения жизни этого человека,
что изменив бизнес процессы ты улучшишь свою жизнь
шутка конечно. но кто его знает.

Ага, а потом нажмет кнопку и устоит всем ERP Скайнет "хэппи энд" и будут ходить модули системы типа Т-800 по планете и разговарить за жизнь миниганами.

Смотрели
Нам такого будущего не нать. И нью васюков через поколения тоже. Мы ж сегодня живем и работаем.
Но лень двигатель прогресса - потому кто-то особо ленивый когда-нть напишет в АХ получение визуальной дельты функционала на скорм слоев от сервис-паков.

Пока же при желании узнать полный список нововведений в системе, нужно залить сервис пак в ЮСР слой, как ХРО, получить дельту и гулять по ней (функционал папки old в этом плане работает не так качественно, как ХРО заливка).

[Evgeniy2020]

Стоп кран у темы улетел и не обещал вернутся.

Новые инструменты не направлены на изменение методологии.
Еще раз говорю методологию в принципе не меняем.

Цитата:

Вы же пытается идти от концепции "А что система принципиально может". Это в корне неверно.

Честно говоря такой вопрос часто задают наверно Директора предприятий,
особенно на тендерах А что система принципиально может?
и такой же вопрос возникает на GAP анализе, а шо наша система принципально может в такой то и такой то области (учета, планирования, управления).

как нам наши бизнес функции эффективно реализовать в нашей системе (и шо она принципиально может дать) как мы эффективно реализуют в системе за счет ее функциональных возможностей. классно когда система функционально безгранична. тогда на ней без труда программистов можно эффективно реализовать что угодно. любую потребность бизнеса.
но сейчас не идет речь о безграничных системах, а именно об ограниченных и наполненных какими то функциональными возможностями,

в случае функционального GAP мы и дорисовываем эту функции в системе.
(консультант ТЗ программер вносит эти изменения) создавая наращивая функциональность закрывая GAP.

никто не отменял схему
Бизнес ---> что нужно бизнесу (бизнес аналитик) работает с инвентаризацией и оптимизирует с ключевыми польз. ----> что есть (консультант) пишет тз -------> программист вносит изменения ------> Аксапта (днк в аот)

конечно хуже когда бизнес выравнивается под возможности ERP в корне неправильно от этого бизнес может потерять какие то конкурентные преимущества.

по прежнему потребности бизнеса являются главными, а ERP обязана предложить максимальное количество возможностей для максимально эффективной реализации этих потребностей в системе.

только инструменты не меняют саму методологию, они лишь ее ускоряют.
и повышают качество реализации все той же знакомой методологии.

только развитие системы не прекращается они периодически продолжается,
если есть какие то GAP, изменения законодательства, внешние требования на рынке.


вывод инструменты не меняют саму методологию они помогают методологии работать качественнее быстрее дешевле

слава труду

кстати я верю что наверно искусственный интеллект появится где то в аксапте когда в результате развития OLAP и продвинутых средств data mining система вдруг в своем мета коде увидит себя,
сделает выводы, начнется безконтрольный рост репозитария изменений и отражения действительности, репозитарий начнет пухнуть, и система вдруг оживет.

[Morpheus]

Готов БЕСПЛАТНО составить документ который отказывается сделать упомянутая Вами консалтинговая компания. В документе будет описание и анализ модификаций, а также аргументированное обоснование какие из них переносить в AX 2009 и какие - нет. А также оценка трудозатрат и дополнительных рисков при upgrade(е). Но есть одно маленькое условие...