Позвоните нам: +7 (4752) 56-46-75

IT изнутри: внедрение информационных систем. Часть II – «Выявление потребностей»

В продолжение предыдущей части (см. IT изнутри: внедрение информационных систем. Часть I – «Сложности»), хочу рассмотреть необходимость выявления потребностей бизнеса, а также пути выявления острых задач автоматизации.

Самым трагичным решением руководителей предприятия и IT-службы в сфере автоматизации является решение начать автоматизацию в режиме "как есть", без анализа и реинжиниринга потребностей бизнеса и бизнес-процессов.

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

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

 

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

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

Для составления портрета "как-есть" необходимо работать с непосредственными исполнителями (на местах).

Сопоставление двух портретов даст необходимую "дельту", с которой и необходимо работать.

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

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

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

 

Последнее изменение...Понедельник, 30 Сентябрь 2013 01:02
Оцените материал
(0 голосов)
Наверх
Оставьте свой email и оставайтесь с нами на связи