|
Исторически заказчиков информационных систем на платформе 1С, и не только, можно поделить на три условных группы:
|
||
|
|
||
|
И мало кто из заказчиков задумывается о таком этапе выполнения проекта как "моделирование", порой называя его "предпроектным обследованием", т.е. относят не к полноценной части проекта, а только к малозначительной подготовительной работе. В то же время мы, специалисты-внедренцы, считаем данный этап очень важным. |
||
|
Если вернуться к условному разделению клиентов на группы, то правы представители и второй, и третьей групп. Чтобы успешно внедрить информационную систему, нужно понять, куда мы целимся. Для этого необходимо сначала собрать все требования, а затем придумать и описать, как они должны быть реализованы. Именно для этих целей и служит ТЗ. Важно отметить, что часто сложным является даже не проектирование, а "просто" сбор требований пользователей. Подробнее об этапе сбора требований можно прочитать ЗДЕСЬ. |
||
|
Итак, требования собраны. Далее систему нужно спроектировать. В традиционном представлении об этапе проектирования думают как об этапе составления технического задания для разработки внедряемой системы. Но что если система уже существует? В этом случае правильным будет не пытаться изобрести велосипед, а использовать уже проверенный практикой функционал. Этот функционал может даже где-то не идеально подходить заказчику, зато его внедрение намного дешевле и перспективнее, т.к. будет шанс бесплатно получать типовые обновления функционала. Таким образом, задача превращается из написания "абстрактного" ТЗ в поиск способа наиболее эффективно решить задачу с помощью уже имеющейся системы. И именно этот процесс мы называем "Моделированием". |
||
|
Как знают продвинутые заказчики, одной из больших проблем в разработке информационных систем является отсутствие однозначного понимания текстов технических заданий и требований всеми участниками процесса. Есть бессчетное число примеров, когда после очень долгого сбора требований и написания технического задания - итоговая система не особо устраивает заказчиков, чьи требования, формально, были полностью учтены в ТЗ. Причина этого очень проста - не видя итогового результата очень сложно себе представить в голове итоговую систему, и это представление может быть разным у заказчиков и исполнителей. В качестве решения этой проблемы, в мире разработки коммерческого ПО уже давно лучшей практикой признана т.н. "итеративная разработка" или Agile, когда все функции реализуются постепенно, с демонстрацией промежуточного результата заказчику, чтобы он мог на более раннем этапе внести свои корректировки. |
||
| Подробнее о ключевой роли этапа моделирования можно прочитать ЗДЕСЬ. | ||
|
На практике среди ряда последних проектов по внедрению 1С:ERP, выполненных автором данной статьи, общие трудозатраты на проект выглядели примерно следующим образом. |
||
|
|
||
|
Вместо послесловия В индустрии разработки программного обеспечения есть классический коллаж, иллюстрирующий разработку системы путем подготовки ТЗ вместо постепенного итеративного подхода. Он выглядит так: |
||
| Если возникли вопросы по этапам внедрения 1С: ERP – обращайтесь! | ||
|
Олег Демиденко, |
