Проекту быть, что дальше? Или использование модульного подхода и спиральной модели при выполнении проекта

Анастасия Смолина, руководитель проектов департамента КИС, ФИНЭКС Качество

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

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

Рассмотрим две возможные ситуации:

Заказчик на момент инициации проекта понимает, какой эффект он хочет получить от внедрения системы. К выбору системы он подошел основательно и имеет представление, с какими ограничениями ему придется смириться, выбирая ту или иную систему. Он может подробно изложить, как должен работать тот или иной процесс в системе, какие данные  имеются на входе и какие данные должны быть на выходе. Если вам попался проект с таким заказчиком, то могу сказать - вам очень сильно повезло. Как правило, успех такого проекта обеспечен с самого начала.

Заказчик в силу требований законодательства, удаленности подразделений или иных факторов принимает решение «проекту быть». Но он не понимает, какой эффект хочет получить от внедрения СЭД. Вся ответственность в успехе проекта в данном случае ложится на исполнителя и зависит от выбранного подхода при реализации проекта. Если вам предстоит реализовывать такой проект, не стоит отчаиваться. Про себя могу сказать такие проекты я люблю, в них появляется большое поле для творчества.

Именно о работе с проектами, описанными во втором варианте, и хочется поговорить.

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

Модульное внедрение

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

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

Тут также не стоит торопиться и автоматизировать все оставшиеся процессы одновременно. Как правило, у каждого процесса есть свои владельцы. Необходимо определиться с блоком процессов, которые относятся к одному владельцу (например, относящихся канцелярия) и приступить к автоматизации данного блока. После того, как блок канцелярии будет завершен, охват сотрудников, работающих в СЭД в этом подразделении, будет максимальным.

Спиральная модель разработки

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

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

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

Что мы получим от применения модульного подхода и спиральной модели?

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

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

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

* * *

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