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

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

Так, реалии рынка дали толчок развитию неординарного и порой рискованного подхода – итерационного сокращенного внедрения, которое позволило с максимальной эффективностью в кратчайшие сроки внедрить систему электронного документооборота и обеспечения взаимодействия DIRECTUM.

Подготовка

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

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

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

Внедрение

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

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

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

  1. Исследование процессов заказчика. Изучались текущие процессы по каждому блоку. Результаты документировались «по-быстрому», «от руки». В итоге получили первоначальные схемы процессов «как есть», общее понимание, как все устроено, и просто познакомились с основными исполнителями, что тоже немаловажно.
  2. Оценка применимости «коробки» и первоначальная проработка решения. Более детально прорабатывались и разбирались схемы, полученные на первом этапе. Далее они перестраивались с учетом стандартных возможностей DIRECTUM и повторно демонстрировались заказчику. Так мы выясняли, правильно ли поняли друг друга и насколько внесенные изменения «ложатся» на процессы. На выходе получали первоначальные схемы процессов «как будет», описанные в нотации в электронном виде.
  3. Демонстрация для рабочей группы. Самый интересный и эмоциональный этап проектирования, в ходе которого обсуждались схемы процессов с рабочей группой. Главная задача – окончательно решить, как будут выглядеть процессы. Всем участникам выдавались распечатанные схемы, а алгоритм рисовался на маркерной доске с подробным объяснением каждого этапа. По итогам таких совещаний (а их могло быть несколько, и некоторые длились по полдня) рождалась итоговая схема работы.
  4. Настройка и адаптация системы. Разработанная в ходе совещания схема работы реализовывалась в СЭД. Параллельно готовились инструкции пользователей.
  5. Демонстрация работы в системе DIRECTUM для всех участников процесса. На этом этапе проводилась демонстрация по каждому процессу для основных действующих лиц: с помощью проектора подробно показывалась работа в СЭД, объяснялись основные особенности реализации и ограничения. Главная цель таких демонстраций – показать, как людям предстоит работать, а также морально настроить на предстоящую работу. Параллельно собирались замечания, которые тут же либо отклонялись, либо брались в работу.
  6. Опытно-промышленная эксплуатация. Главной особенностью было то, что чем больше процессов со временем было запущено, тем большее их количество приходилось одновременно поддерживать команде внедрения. Однако основные корректировки по предыдущим блокам к моменту запуска следующего обычно уже были выполнены, что упрощало дело. Ну и нельзя не отметить, что с каждым днем заказчик становился все опытнее и «бытовые» консультации можно было перекладывать с команды внедрения исполнителя на плечи ответственных со стороны заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

1) небольшой бюджет и сжатые сроки;
2) относительно малое число пользователей СЭД;
3) согласие заказчика подстраиваться под стандартные возможности системы, а не только адаптировать систему под процессы;
4) отсутствие бюрократии и возможность быстро принимать решения;
5) возможность предоставить удаленный доступ к СЭД (в противном случае выполнять работы будет затруднительно);
6) возможность и желание заказчика уделять проекту не менее 50% своего времени, а также идти на компромиссы;
7) способность команды внедрения работать на протяжении всего проекта в активном режиме: параллельные работы, постоянное взаимодействие с заказчиком, сжатые сроки.

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