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

Подготовка

Приступая к новому проекту, мы снова оказались перед выбором, как внедрять. На входе мы имели: разнородные блоки процессов, короткие сроки, небольшой бюджет и учет затрат в еженедельных табелях, двух участников от исполнителя (руководитель проекта и бизнес-аналитик в одном лице; разработчик), заранее обученного администратора DIRECTUM, дружелюбного и открытого заказчика, а также твердое намерение сделать всё как можно лучше.

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

Внедрение

Первое, что было сделано, — проведены исследование процессов и примерная оценка, насколько «коробка» справится с поставленными задачами. Параллельно рабочая группа прошла обучение основам работы в системе DIRECTUM.

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

Как был выстроен процесс «подгонки» системы под заказчика.

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

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

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

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

5. Демонстрация работы в системе DIRECTUM для всех участников процесса. Цель демонстраций — показать, как людям предстоит работать, и морально настроить на то, что это скоро случится. Параллельно собирались замечания, которые тут же либо отклонялись, либо брались в работу.

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

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

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

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

  • Ошибки в проектировании, появление новых и изменение существующих требований. Для исключения ошибок подробно разбирали все принимаемые решения и требования. Делали всё, чтобы рабочая группа до конца поняла, что будет в результате, и продумала все варианты использования. К слову, доработок и изменений после запуска в ОПЭ было немного.
  • Разногласия с заказчиком во время ОПЭ по поводу того, что делаем, а что нет. Чтобы нивелировать этот риск, постарались установить доверительные взаимоотношения с заказчиком. Вдобавок к этому активно прививали понимание, что всё и сразу реализовать в рамках ограничений проекта мы не сможем.
  • Замечания от пользователей из-за укороченной ОПЭ и отсутствия тестовой эксплуатации. Проблема решалась детальным устным обсуждением на этапе проектирования, а также подготовкой заказчика к тому, что доработка и развитие системы будут продолжаться и после окончания проекта внедрения.

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

  • небольшой бюджет и сжатые сроки;
  • относительно малое количество пользователей СЭД;
  • согласие заказчика подстраиваться под стандартные возможности системы, а не только адаптировать ее под процессы;
  • отсутствие бюрократии и быстрое принятие решений;
  • возможность предоставить удаленный доступ к СЭД (в противном случае при таком варианте внедрения выполнять работы будет затруднительно);
  • возможность и желание заказчика уделять проекту не менее 50% своего времени, а также идти на компромиссы;
  • способность команды внедрения на протяжении всего проекта работать в активном режиме — параллельные работы, постоянное взаимодействие с заказчиком, сжатые сроки.

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

Автор статьи — руководитель проектов внедрения DIRECTUM.

СПЕЦПРОЕКТ КОМПАНИИ DIRECTUM