Формализм, за и против…

Работая на проектах или поддержке системы, мы часто слышим предложения, звучащие от оппонентов, руководства, коллег: «Давайте обойдемся без лишнего формализма».  И сразу все окружающие начинают согласно кивать головами, и настроение у всех поднимается, и даже хочется предложить открыть бутылочку и отметить такое светлое решение… Но есть ли здесь повод для радости? Я, например, к таким предложения отношусь не лучше, чем к предложению отведать  протухшего арбуза. Чем нам грозит отказ от «лишнего» формализма, и бывает ли формализм лишним.

Начну с выведенным мной за проектную деятельность заключением: Лишнего формализма не бывает, бывает лишь неправильно организованный процесс». При этом соблюдение формальностей часто является единственным способом заказчику и исполнителю к концу проекта остаться друзьями.

А теперь я попытаюсь обосновать своё высказывание.

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

Вы как РП, тим-лид и т.д. начинаете постоянно отвечать на вопросы подчиненных: «С кем и как мне договориться о встрече». Что вы на это предпринимаете? Звоните Марье Ивановне, она, уже замученная вашими звонками, начинает искать контакты, договариваться с людьми (выслушивая при этом их отговорки, в лучшем случае).

Когда необходимо согласовать какой-либо документ (проектное решение, ТЗ и т.д.) все документы валятся на вас, а вы в дальнейшем  пересылаете их Марье Ивановне с просьбой сделать рассылку согласующим, обратная связь идет тоже через неё — получаем бутылочное горлышко, в котором документы или их версии (с версиями самое сложное) не только застревают, но и могут потеряться. Либо второй вариант – консультанты, с вашего ведома, начинают рассылать документы тем людям, кому они считают нужным. Не факт, что их мнение правильное. Данный процесс сопровождается рисками кого-то забыть или запустить документ на согласование тем, кто не уполномочен принимать подобные решения.

В конечном итоге к середине или концу проекта у вас всё-таки будет  сформирован план коммуникаций (в голове, в личных договоренностях, распоряжениях и т.д.), но все это будет сделано на фоне замученной Марьи Ивановны, пары скандалов, испорченных отношений и затягивании сроков из-за неразберихи.

А в чем корень зла? Да просто при подготовке документов по управлению проектами кто-то добрый решил отказаться от «лишнего формализма». А ведь мы даже не затронули вопрос кадровых перестановок, при которых проект трудно удержать от «болтанки», даже имея железные тылы. Ведь новые люди, приходя на места ушедших, не спешат выполнять даже оформленные и завизированные соглашения, не говоря уже об устных договоренностях.

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

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

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

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

  2 Ответов в “Формализм, за и против…”

  1. Полностью согласна!
    Не раз уже сталкивалась с проблемами, которые могли бы решиться гораздо быстрее, зная точно к кому обращаться по тому или иному вопросу. Конечно, Марья Ивановна должна быть на проекте, своего рода координатор – будет соединять ответственных со стороны заказчика и консультантов исполнителя.
    Частенько бывают ситуации, когда на очередном совещании с заказчиком , посвященном какой-нибудь теме , решается сделать доработку в системе. Всем эта функция нужна, все согласны с ее условиями, все устно обговорили и договорились между собой о примерных сроках реализации. Однако, когда уже готово проектное решение по доработке системы – нет ответственных по данному вопросу со стороны заказчика. И уже это доработка всем не так уж и нужна ( нужно же тратить время на тестирование, выявление недочетов , снова тестирование…) . В итоге консультант потратил время на проектное решение , руководитель уже определился с трудозатратами ,а про задачу уже все забыли.
    Бывает и обратная ситуация. Когда заказчик спустя месяц интересуется — что там с его «хотелкой». Но никто не занимался его вопросом – т.к. либо просто забыли, либо все время переносили начало разработки «на завтра» — все равно же ничего не согласовано и сроки нигде не прописаны.

  2. Основная мысль, несомненно, правильная, хоть и раскрыта поверхностно и, извините, непрофессионально. Говорю это как PMP by PMI :) и человек с 20-летним стажем внедрения ERP-систем.
    Но я Вас умоляю — прекратите говорить «внедряется проект»! Что ж это за беда-то такая? Ведь не самые глупые люди занимаются этим бизнесом, а элементарной грамотности нет!
    Внедряются информационные системы, или стандарты, или методы, или корпоративные политики, процедуры, агенты, разведчики….
    А проекты реализуются, осуществляются, выполняются, на худой конец, делаются.
    «Проект — это временное предприятие, предназначенное для создания уникального продукта, услуги или результата» (PMBOK). Предприятие здесь — в смысле деятельность.
    Проект — это совокупность активностей (работ, мероприятий), в частном случае, направленных на внедрение ERP-системы. Хотя и здесь неточность перевода соединилась с непониманием сути. Implementation (англ.) — реализация, осуществление, выполнение. ERP — прежде всего, управленческая концепция, которую можно воплотить, используя как интегрированную ИС, так и несколько ИС. На Западе (я с этим столкнулся в той же Германии), словосочетание «ERP Implementation» означает реализацию на предприятии концепции ERP с применением ИТ. Т.е. «ERP implementation» — это не ИТ-проект, это — инвестиционный проект осуществления соответствующих организационных изменений. А у нас почти все сводится к инсталляции ИС (утрирую), ибо об изменении управленческой модели никто даже не задумывается. И вообще, сам термин внедрение в русском языке имеет несколько значений, и не соответствует английскому implementation, потому лучше говорить имплиментация. А грамотнее всего вместо «внедрение SAP ERP» (или, например, Oracle e-Business Suite) писать «создание Корпоративной Информационной Системы (КИС) на базе системы SAP ERP». См. определение КИС.
    Тщательнее надо бы…

 
© 2013 sap-blog.ru
Яндекс.Метрика