Технология внедрения ERP. Ключевая роль этапа «Моделирование»

08.09.16

Бизнес-анализ

Большинство внедрений 1С:ERP (Управление торговлей 11, Документооборота) эффективно работают при организации проектирования от возможностей типовой конфигурации. В статье описаны сутьи особенности такого подхода

Исторически заказчиков информационных систем на платформе 1С, и не только, можно поделить на три условных группы:

  • первые не знают, как это будет происходить, их ожидания могут принимать самые разные формы. Начиная от того, что систему им запустят в один день, и кончая отсутствием веры, что запустить её даже теоретически возможно, т.к. "их бизнес уникален".
  • вторые понимают, что доработку системы под их специфику проводить, скорее всего, придется, и ожидают, что проект начнётся с подготовки технического задания (ТЗ).
  • третьи являются наиболее продвинутыми. Или они уже слышали об agile-методологиях, или понимают, что долго писать "большое и светлое" ТЗ – как правило, не самый эффективный путь. Эти люди хотят шаг за шагом, небольшими этапами, внедрять отдельные функции, чтобы быстрее получать полезный результат и контролировать его соответствие своим ожиданиям.

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

Что же мы, специалисты-внедренцы, понимаем под этим этапом, и почему считаем его столь важным? Но сначала надо сказать, что правы представители и второй, и третьей групп клиентов. Чтобы успешно внедрить информационную систему, сначала нужно понять, куда мы целимся. Для этого нужно сначала собрать все требования, а затем придумать и описать, как они должны быть реализованы. Именно для этих целей и служит ТЗ. Тут важно отметить, что часто сложным является даже не проектирование, а "просто" сбор требований пользователей. В проектах не всегда явно выделяют отдельный этап сбора требований (т.к. за него не любит платить заказчик), хотя он, на самом деле, является базой для всего и далеко не всегда легко выполним. Существуют даже международные руководства, посвященные тому, как выявить все требования к информационной системе (business analysis body of knowledge, сокр.BABoK). Что же тут сложного? Когда речь идется о внедрении информационной системы для бухгалтерского и налогового учета - значительная часть требований достаточно понятна, они определены законодательством. Хотя даже в этом случае есть немало пространства для творчества: в одних организациях бухгалтерский учет ведётся и для использования во внутренних целях, подробно и аккуратно; в других его ведут максимально простым способом, и только для целей сдачи отчетности государству. Намного сложнее сбор требований становится в случае отхода от строго технических задач в те области, где большой фактор субъективного видения пользователей. Например, коммерческая деятельность. Хотя есть стандартизированные элементы и понятия (например, "воронка продаж" или "ценовая политика"), но в разных компаниях они могут выглядеть почти принципиально по-разному. В этих сферах даже внутри одной компании у разных менеджеров может быть разное видение того, как составлять отчетность и управлять процессами. Хуже того, у разных групп внутри компании могут быть разные интересы. Например, у рядовых продавцов, начальника отдела продаж и фин..директора взгляды и цели могут быть очень разные: продавцам важно удобство работы программы и выполнение личного плана продаж, руководителю отдела продаж важна общая эффективность продаж, а фин..директора могут интересовать прозрачность бюджетов продаж и стабильный денежный поток. Таким образом, сбор требований - это непростой этап проекта, который зачастую ложится на плечи исполнителя, т.к. заказчикам не хватает времени или опыта на то чтобы непротиворечиво и полно описать потребности всех групп своих сотрудников.

Итак, требования собраны. Далее систему нужно спроектировать. Классически об этапе проектирования думают как об этапе составления технического задания для разработки внедряемой системы. Но что, если система уже существует? В этом случае правильным будет не пытаться изобрести велосипед, а использовать уже проверенный практикой функционал. Этот функционал может даже где-то не идеально подходить заказчику, зато его внедрение намного дешевле и перспективнее, т.к. будет шанс бесплатно получать типовые обновления функционала. Таким образом, задача превращается из написания "абстрактного" ТЗ в поиск способа наиболее эффективно решить задачу с помощью уже имеющейся системы. И именно этот процесс мы называем "Моделированием".

Как знают продвинутые заказчики, одной из больших проблем в разработке информационных систем является отсутствие однозначного понимания текстов технических заданий и требований всеми участниками процесса. Есть бессчетное число примеров, когда после очень долгого сбора требования и написания технического задания - итоговая система не особо устраивает заказчиков, чьи требования, формально, были полностью учтены в ТЗ. Причина этого очень проста - не видя итогового результата очень сложно себе представить в голове итоговую систему, и это представление может быть разным у заказчиков и исполнителей. В качестве решения этой проблемы, в мире разработки коммерческого ПО уже давно лучшей практикой признана т.н. "итеративная разработка" или Agile, когда все функции реализуются постепенно, с демонстрацией промежуточного результата заказчику, чтобы он мог на более раннем этапе внести свои корректировки.

Правильное выполнение этапа моделирования базируется именно на итеративном подходе. Сначала собираются  ключевые требования Заказчика, исполнитель продумывает, как их воплотить, и сразу готовит демонстрацию способа их воплощения в информационной системе. Клиент быстро видит обратную связь, понимает, устраивает ли его предложенный подход (часто существует несколько альтернатив) и даёт более детальные требования к нюансам бизнес-процессов. Таким образом, заказчик всё время видит финальный результат, детализация проработки которого будет постепенно увеличиваться. Такой многоэтапный подход к уточнению требований можно сравнить с наведением резкости на фотоаппарате - постепенно картинка становится всё более и более чёткой. В противоположность этому, при подготовке ТЗ без промежуточных демонстраций Заказчик сразу увидит конечную картинку, но, возможно, совсем не с того ракурса, который он хотел бы.

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

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

На практике, среди ряда последних проектов по внедрению 1С:ERP, выполненных автором данной статьи, общие трудозатраты на проект выглядели примерно следующим образом:

  • 2-5% - предпроектное обследование
  • 40-70% - моделирование
  • 10-20% - доработка функционала (печатные формы, отраслевая специфика)
  • 0-30% - перенос данных из старых систем, очистка от ошибок, унификация и т.п.
  • 1-5% - документация
  • 5-15% - обучение пользователей

Вместо послесловия

В индустрии разработки программного обеспечения есть классический коллаж (см.ниже), иллюстрирующий разработку системы путем подготовки и согласования бумажного ТЗ, вместо постепенного итеративного согласования и улучшения прототипа системы. Моделирование, как пример итеративной методики, не избавляет от указанных проблем, но позволяет быстро сопоставить результат с видением заказчика, и исправить расхождения, если они возникнут.

Что хотел заказчик, и что получил в конце

ERP управление проектами

См. также

Внедрение изменений Бесплатно (free)

Внедрение дорогих и сложных решений вроде BI, MDM, CRM или УХ для вспомогательных целей – не единственный путь, а порой и вовсе тупиковый. Расскажем о том, как не попасть в УХу, если директор хочет красивые отчёты, и делать дешёвые интеграции, не заморачиваясь с поиском специалистов по Конвертации данных.

01.04.2025    3998    0    1c-intelligence    18    

33

Анализ потребностей и поиск решений Архитектура решений Бесплатно (free)

В четырнадцатом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, что из себя представляют облачные технологии и какие возможности они предоставляют для работы с решениями 1С.

11.03.2025    362    0    Radio_Analyst    0    

5

Работа с требованиями Анализ предметной области Бесплатно (free)

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

04.03.2025    437    0    SerjoginaMaria    0    

5

Проектирование Сопровождение Внедрение изменений Бесплатно (free)

Для эффективного развития направлений разработки и внедрения 1С в огромной корпорации нужны особые организационные и технологические механизмы. Расскажем о создании фабрики подрядчиков и автоматизации процессов разработки с помощью «Умного облака 1С».

03.03.2025    956    0    shadenew    1    

8

Взгляд со стороны Заказчика Внедрение изменений Кейсы автоматизации Бесплатно (free)

Всем участникам проектов внедрения знакомы пять главных «НЕ»: НЕправильно просчитанный бюджет; НЕзаинтересованность руководства; НЕпрочное целеполагание; НЕреализованные ожидания заказчика; НЕжелание пользователей сотрудничать. Расскажем о том, какие инструменты помогут обойти эти препятствия и не похоронить проект.

21.02.2025    844    0    KrisSh    0    

7

Работа с требованиями Анализ бизнес-процессов Анализ предметной области Бизнес-аналитик Бесплатно (free)

Искусственный интеллект (ИИ) уже достаточно сильно проникает во все области. Не исключена и область работы аналитиков 1С. В этой статье я порассуждала, как ИИ может положительно повлиять на его работу. Но начну я с сентиментального рассказа «Маленький Аналитик 1С и Планеты Софт-Скиллов».

07.02.2025    2996    0    ashtey    7    

18

Внедрение изменений Бесплатно (free)

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

24.01.2025    652    0    dabu-dabu    0    

7

Внедрение изменений Бухгалтер Платформа 1С v8.3 Бухгалтерский учет 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

При переходе компании с устаревших решений, таких как 1С:УПП, важно определиться, где будет вестись бухгалтерский учет – в 1С:ERP или в 1С:Бухгалтерии. Расскажем об особенностях и принципиальных различиях ведения регламентированного учета в 1С:ERP и 1С:БП – на что нужно обратить внимание при обследовании, какие вопросы задать клиенту, чтобы в конечном итоге сделать правильный выбор в пользу одной или другой программы.

17.01.2025    2506    0    user1455139    7    

22
Оставьте свое сообщение