Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

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

  0 комментариев Добавить в закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* * *

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

Ещё материалы автора
Похожие записи
Комментарии (0)
Сейчас обсуждают
Больше комментариев