Управление пожеланиями к информационной системе
Стремление постоянно совершенствовать работу информационной системы – это замечательно. Но всегда ли улучшения дают положительный результат? Эта заметка о том, кто, как и когда должен принимать решения о внесении изменений в ИС.
– Сделайте мне ещё один отчет.
– Давайте к процессу планирования привлечем специалистов удаленных подразделений.
– Хочу волшебную кнопку «Сделать всё за меня!»..
Знакомая картина? Думаю, да. При внедрении информационной системы на предприятии заказчика консультанты и руководители проектов сталкиваются с потоком пожеланий к системе, к схемам бизнес-процессов и т.д. Пожелания высказывают все – и руководители, и рядовые пользователи.
Тут встает вопрос: кто будет принимать решение о том, что будет взято в работу, а что не будет реализовано? Такие решения должно принимать руководство со стороны заказчика, т.к. именно оно владеет информацией о том, какие задачи в целом должна решать система, что должно быть на выходе и есть ли финансовая возможность реализовывать дополнительные пожелания. При этом можно и нужно прибегать к консультациям компании-внедренца, т.к. за счет большого опыта их специалисты смогут подсказать оптимальное решение вопроса.
Теперь том, как принимать решения реализовывать либо не реализовывать пожелание. Если эффект от реализации действительно будет стоить затраченных ресурсов, то пожелание следует реализовать. Иначе не стоит. Давайте рассмотрим пару ситуаций:
Пример 1. Пользователю нравится, когда при запуске отчета он может указывать множество разных параметров, чтобы получать данные в необходимых разрезах. Он постоянно просит добавить дополнительный параметр. При этом у него есть все необходимые данные в отчете, и он может пользоваться обычными фильтрами. К тому же перезапуск отчета с другими параметрами займет больше времени, чем установка фильтра в отчете. В этом случае модификации, как вы сами понимаете, не нужны. Достаточно научить специалиста грамотно пользоваться фильтрами в отчете.
Пример 2. Появляется пожелание добавить «волшебную» кнопку, формирующую графики платежей по договорам автоматически. Начинаем разбираться. Графики могут быть достаточно большими, например, ежемесячные платежи по договору, длящемуся несколько лет. На каждый из них тратится от 10 до 30 минут рабочего времени. У пользователей может быть по 3-5 новых договоров в день. Получается, что примерно 2 часа рабочего времени специалисты будут тратить на забивание информации, которую можно сформировать автоматически за пару секунд. Затраты на создание «волшебной» кнопки будут гораздо меньше. Вывод о необходимости создания такой кнопки очевиден.
Я описала две реальные ситуации наших заказчиков, но их гораздо больше, каждое пожелание надо рассматривать отдельно.
Ещё один вопрос – когда лучше высказывать пожелания. Руководству предприятия важно донести до сотрудников, что основной поток требований должен быть озвучен на этапе исследования. Это поможет компании-внедренцу спроектировать систему, максимально удовлетворяющую потребностям заказчика, и позволит избежать дополнительных модификаций, считай затрат, в ходе внедрения. Этап исследования - это тот период, когда специалисты компании-внедренца будут рассматривать все, даже самые мелкие замечания. При согласовании проекта будущей ИС предприятия очень важно внимательно ознакомиться с проектными решениями, т.к. на этом этапе достаточно легко что-то скорректировать «на бумаге». Кстати, если очень хочется посмотреть, как же будут выглядеть карточки документов и справочников, с которыми вы будете работать, перед началом проектирования можно попросить внедренцев нарисовать прототипы. Так легче оценить насколько удобно будет работать в будущем.
В процессе опытной эксплуатации системы пожелания, так или иначе, появляются. Вариантов их реализации может быть несколько:
● Если пожелания выходят за рамки целей и задач, определенных проектными решениями, то автоматизировать их нужно за рамками проекта:
● Силами своего ИТ-отдела. Это дешевле, чем привлекать сотрудников компании-внедренца. Ведение одновременной разработки двумя командами не рекомендуется, т.к. вносимые модификации одной из команд могут «затереть» изменения системы, которые реализовывала другая команда.
● Силами внедренцев. Это позволит вовремя получить основные результаты по проекту, но будет стоить дополнительных финансовых вложений.
● Если же требования входят в рамки целей и задач проекта и их автоматизация приведет к повышению качества ИС, то реализовать их нужно силами внедренцев в рамках проекта. Но надо понимать, что перечень таких пожеланий должен быть ограниченным. Иначе есть риск не закончить проект вовремя, а значит не начать вовремя планирование бюджета, успеть пропустить ещё с десяток платежей сверх лимита и т.д.
Напоследок хочется отметить, что наверняка все внедренцы мечтают о том, чтобы их проекты проходили гладко. Заказчики же мечтают получить систему, в которой будут учтены все пожелания. Если уметь грамотно ими управлять, мечты могут стать реальностью.
Довольствуйся настоящим, но стремись к лучшему. (Сократ)
Автор: Микешкина Евгения, консультант-менеджер отдела консалтинга и внедрения корпоративных систем управления НПО «Компьютер»