Итерационное сокращенное внедрение СЭД, или Давай сделаем это по-быстрому

Вячеслав Филиппов, руководитель проектов внедрения DIRECTUM.

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

Подготовка

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

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

От максимального каскадного и итерационного внедрения отказались сразу – дорого и долго. Сокращенное внедрение (учесть все требования, не зная, чего хочется?) – сомнительно, хотя уже ближе. В итоге было принято решение опробовать минимальное по затратам и срокам внедрение с поэтапным вводом процессов в опытно-промышленную эксплуатацию (ОПЭ).

Внедрение

Первое, что было сделано – проведены исследование всех автоматизируемых процессов и примерная оценка того, насколько «коробка» справится с решением поставленных задач. Для рабочей группы параллельно было проведено обучение по основам работы в СЭД.

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

Итак, как же был выстроен процесс «подгонки» системы под заказчика:

1.   Исследование процессов заказчика. Изучались текущие процессы по каждому блоку. Результаты документировались по-быстрому «от руки». В итоге получили первоначальные схемы процессов «как есть», общее понимание, как все устроено, и просто познакомились с основными исполнителями, что тоже немаловажно.

2.   Оценка применимости «коробки» и первоначальная проработка решения. Более детально прорабатывались и разбирались полученные на первом этапе схемы. Далее они перестраивались с учетом стандартных возможностей СЭД и повторно демонстрировались заказчику. Так мы выясняли, правильно ли поняли друг друга и насколько внесенные изменения «ложатся» на процессы. На выходе получали первоначальные схемы процессов «как будет», описанные в нотации в электронном виде.

3.   Демонстрация для рабочей группы. Самый интересный и эмоциональный этап проектирования – обсуждение схем процессов с рабочей группой, главная задача – принять окончательное решение, как будут выглядеть процессы. Всем участникам выдавались распечатанные схемы, а сам алгоритм рисовался на маркерной доске с подробным объяснением каждого этапа. По итогам таких совещаний, а их могло быть несколько, и некоторые длились по полдня, рождалась итоговая схема работы.

4.   Настройка и адаптация системы. Разработанная в ходе совещания схема работы реализовывались в СЭД. Параллельно готовились инструкции пользователей.

5.   Демонстрация работы в СЭД для всех участников процесса. На текущем этапе проводилась демонстрация процессов для основных действующих лиц по каждому процессу: используя проектор, подробно показывалась работа в СЭД, объяснялись основные особенности реализации и ограничения. Главная цель таких демонстраций – показать то, как людям предстоит работать, а также морально настроить, что скоро это случится. Параллельно собирались замечания, которые тут же либо отклонялись, либо брались в работу.

6.   Опытно-промышленная эксплуатация. Главной особенностью было то, что чем, больше процессов со временем было запущенно, тем большее их количество приходилось одновременно поддерживать команде внедрения. Однако это балансировалось тем, что основные замечания по предыдущим блокам, к моменту запуска следующего, обычно уже были исправлены. Ну и нельзя не отметить, что с каждым днем заказчик становился все опытнее, и «бытовые» консультации можно было перекладывать с команды внедрения исполнителя на плечи ответственных.

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

План-график процесса внедрения

Проблемы и рекомендации

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

●    Ошибки в проектировании, а также появление новых и изменение существующих требований.

Для исключения ошибок, подробно разбирали все принимаемые решения и требования в устных беседах. Делали все, чтобы рабочая группа до конца поняла, как все будет и продумала все варианты использования. И надо сказать, что доработок и изменений после запуска в ОПЭ было немного.

●    Конфликты с заказчиком вовремя ОПЭ, связанные с тем, что требования детально не фиксировались, а это в свою очередь могло привести к разногласиям по поводу того, что делаем в рамках проекта, а что нет.

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

●    Появление замечаний от пользователей после завершения проекта из-за отсутствия тестовой эксплуатации и укороченной ОПЭ.

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

Несмотря на все сложности, методология может использоваться и быть эффективной, если имеем:

●    Небольшой бюджет и сжатые сроки.

●    Относительно малое количество пользователей СЭД.

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

●    Отсутствие бюрократии и возможность быстро принимать решения.

●    Возможность предоставить удаленный доступ к СЭД. В противном случае, при таком варианте внедрения, выполнять работы будет затруднительно.

●    Возможность и желание заказчика уделять проекту не менее 50% своего времени, а также идти на компромиссы.

●    Способность команды внедрения работать на протяжении всего проекта в активном режиме: параллельные работы, постоянное взаимодействие с заказчиком, сжатые сроки.

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

Источник: PCweek