В прошлом материале мы разобрали, как работают консультанты на старте проекта по автоматизации финансового планирования. В этой статье разберем этап разработки системы для финансового планирования.
Кратко напомним, что на старте команда консультантов ознакамливается с файлами заказчика, чтобы понять связи между показателями таблицами и справочниками, проводит подробное интервью, где выявляются приоритетные цели и задачи, и предлагает первичный проект архитектуры в виде блок-схемы.
После согласования проекта архитектуры системы финансового планирования консультанты приступают собственно к разработке.
Очередность задач для построения архитектуры выбирает заказчик, при этом есть два варианта реализации: quick wins и полная разработка.
После согласования проекта архитектуры системы финансового планирования консультанты приступают собственно к разработке.
Очередность задач для построения архитектуры выбирает заказчик, при этом есть два варианта реализации: quick wins и полная разработка.
Quick wins в автоматизации финансового планирования
Подход quick wins, или быстрых побед, предполагают, что за относительно короткий срок заказчик получит готовой небольшую задачу, на которой сможет посмотреть работу системы.
В этом случае консультанты берут несколько форм бизнес-процесса, который автоматизируют, разрабатывают под них справочники, формы, налаживают связи и проводят обучение. При таком подходе, заказчик уже через несколько недель может работать в системе.
В этом случае консультанты берут несколько форм бизнес-процесса, который автоматизируют, разрабатывают под них справочники, формы, налаживают связи и проводят обучение. При таком подходе, заказчик уже через несколько недель может работать в системе.
Полный цикл разработки в автоматизации финансового планирования
Второй подход, полная разработка, предполагает, что консультанты поэтапно разрабатывают все формы, уточняют и согласовывают архитектуру на каждом этапе, совместно с заказчиком работают над методологическими и техническими вопросами.
Этот вариант предполагает, что клиент полностью вовлекается в проект на этапе тестирования финальной модели.
Этот вариант предполагает, что клиент полностью вовлекается в проект на этапе тестирования финальной модели.
Часто получается, что заказчикам представляется более интересным первый вариант реализации проекта, quick wins, однако клиенту бывает сложно в момент готовности пилота выделить ресурсы для обучения и тестирования системы. На этом моменте может произойти разворот ко второй стратегии - реализации полного проекта.
В следующем материале поговорим о клиентском тестировании и доработках уже в готовой системе.
