Исторически заказчиков информационных систем на платформе 1С, и не только, можно поделить на три условных группы:
- первые не знают, как это будет происходить, их ожидания могут принимать самые разные формы. Начиная от того, что систему им запустят в один день, и кончая отсутствием веры, что запустить её даже теоретически возможно, т.к. "их бизнес уникален".
- вторые понимают, что доработку системы под их специфику проводить, скорее всего, придется, и ожидают, что проект начнётся с подготовки технического задания (ТЗ).
- третьи являются наиболее продвинутыми. Или они уже слышали об agile-методологиях, или понимают, что долго писать "большое и светлое" ТЗ – как правило, не самый эффективный путь. Эти люди хотят шаг за шагом, небольшими этапами, внедрять отдельные функции, чтобы быстрее получать полезный результат и контролировать его соответствие своим ожиданиям.
И мало кто из заказчиков, на самом деле, задумывается о таком этапе выполнения проекта, как "моделирование". Или они называют это "предпроектным обследованием", т.е. уничижительно относят это не к полноценной части проекта, а только какой-то малозначительной подготовительной работе.
Что же мы, специалисты-внедренцы, понимаем под этим этапом, и почему считаем его столь важным? Но сначала надо сказать, что правы представители и второй, и третьей групп клиентов. Чтобы успешно внедрить информационную систему, сначала нужно понять, куда мы целимся. Для этого нужно сначала собрать все требования, а затем придумать и описать, как они должны быть реализованы. Именно для этих целей и служит ТЗ. Тут важно отметить, что часто сложным является даже не проектирование, а "просто" сбор требований пользователей. В проектах не всегда явно выделяют отдельный этап сбора требований (т.к. за него не любит платить заказчик), хотя он, на самом деле, является базой для всего и далеко не всегда легко выполним. Существуют даже международные руководства, посвященные тому, как выявить все требования к информационной системе (business analysis body of knowledge, сокр.BABoK). Что же тут сложного? Когда речь идется о внедрении информационной системы для бухгалтерского и налогового учета - значительная часть требований достаточно понятна, они определены законодательством. Хотя даже в этом случае есть немало пространства для творчества: в одних организациях бухгалтерский учет ведётся и для использования во внутренних целях, подробно и аккуратно; в других его ведут максимально простым способом, и только для целей сдачи отчетности государству. Намного сложнее сбор требований становится в случае отхода от строго технических задач в те области, где большой фактор субъективного видения пользователей. Например, коммерческая деятельность. Хотя есть стандартизированные элементы и понятия (например, "воронка продаж" или "ценовая политика"), но в разных компаниях они могут выглядеть почти принципиально по-разному. В этих сферах даже внутри одной компании у разных менеджеров может быть разное видение того, как составлять отчетность и управлять процессами. Хуже того, у разных групп внутри компании могут быть разные интересы. Например, у рядовых продавцов, начальника отдела продаж и фин..директора взгляды и цели могут быть очень разные: продавцам важно удобство работы программы и выполнение личного плана продаж, руководителю отдела продаж важна общая эффективность продаж, а фин..директора могут интересовать прозрачность бюджетов продаж и стабильный денежный поток. Таким образом, сбор требований - это непростой этап проекта, который зачастую ложится на плечи исполнителя, т.к. заказчикам не хватает времени или опыта на то чтобы непротиворечиво и полно описать потребности всех групп своих сотрудников.
Итак, требования собраны. Далее систему нужно спроектировать. Классически об этапе проектирования думают как об этапе составления технического задания для разработки внедряемой системы. Но что, если система уже существует? В этом случае правильным будет не пытаться изобрести велосипед, а использовать уже проверенный практикой функционал. Этот функционал может даже где-то не идеально подходить заказчику, зато его внедрение намного дешевле и перспективнее, т.к. будет шанс бесплатно получать типовые обновления функционала. Таким образом, задача превращается из написания "абстрактного" ТЗ в поиск способа наиболее эффективно решить задачу с помощью уже имеющейся системы. И именно этот процесс мы называем "Моделированием".
Как знают продвинутые заказчики, одной из больших проблем в разработке информационных систем является отсутствие однозначного понимания текстов технических заданий и требований всеми участниками процесса. Есть бессчетное число примеров, когда после очень долгого сбора требования и написания технического задания - итоговая система не особо устраивает заказчиков, чьи требования, формально, были полностью учтены в ТЗ. Причина этого очень проста - не видя итогового результата очень сложно себе представить в голове итоговую систему, и это представление может быть разным у заказчиков и исполнителей. В качестве решения этой проблемы, в мире разработки коммерческого ПО уже давно лучшей практикой признана т.н. "итеративная разработка" или Agile, когда все функции реализуются постепенно, с демонстрацией промежуточного результата заказчику, чтобы он мог на более раннем этапе внести свои корректировки.
Правильное выполнение этапа моделирования базируется именно на итеративном подходе. Сначала собираются ключевые требования Заказчика, исполнитель продумывает, как их воплотить, и сразу готовит демонстрацию способа их воплощения в информационной системе. Клиент быстро видит обратную связь, понимает, устраивает ли его предложенный подход (часто существует несколько альтернатив) и даёт более детальные требования к нюансам бизнес-процессов. Таким образом, заказчик всё время видит финальный результат, детализация проработки которого будет постепенно увеличиваться. Такой многоэтапный подход к уточнению требований можно сравнить с наведением резкости на фотоаппарате - постепенно картинка становится всё более и более чёткой. В противоположность этому, при подготовке ТЗ без промежуточных демонстраций Заказчик сразу увидит конечную картинку, но, возможно, совсем не с того ракурса, который он хотел бы.
Обобщая написанное выше, этап моделирования - это процесс постепенного сбора требований, демонстрации способов их воплощения Заказчику, и формулирования концепции необходимых доработок системы (путём настройки типовой системы, или разработки дополнительного функционала). В ходе этапа моделирования также необходимо объяснять ключевым пользователям, как предлагаемая модель настройки типовой системы будет решать их задачи. Для этого проводится объяснение базовых принципов работы системы и происходит постепенное обучение ключевых представителей Заказчика порядку работы с системой. То есть этап моделирования неизбежно включает в себя и частичное обучение ключевых пользователей Заказчика.
Исходя из приведенного описания, становится видно, что роль этапа моделирования при внедрении информационной системы, базирующейся на типовом продукте, является ключевой. В случаях, когда Заказчику, в итоге, подходит типовая система, выполнение моделирования эквивалентно выполнению большей части всего проекта, т.к. после него остается провести только перенос данных в новую систему и детальное обучение всех пользователей.
На практике, среди ряда последних проектов по внедрению 1С:ERP, выполненных автором данной статьи, общие трудозатраты на проект выглядели примерно следующим образом:
- 2-5% - предпроектное обследование
- 40-70% - моделирование
- 10-20% - доработка функционала (печатные формы, отраслевая специфика)
- 0-30% - перенос данных из старых систем, очистка от ошибок, унификация и т.п.
- 1-5% - документация
- 5-15% - обучение пользователей
Вместо послесловия
В индустрии разработки программного обеспечения есть классический коллаж (см.ниже), иллюстрирующий разработку системы путем подготовки и согласования бумажного ТЗ, вместо постепенного итеративного согласования и улучшения прототипа системы. Моделирование, как пример итеративной методики, не избавляет от указанных проблем, но позволяет быстро сопоставить результат с видением заказчика, и исправить расхождения, если они возникнут.
