С момента публикаций первого рассказика из цикла сказов (1, 2, 3, 4) прошло почти 1,5 месяца. В принципе, такой срок может пройти и в реальной жизни с момента первого взгляда заказчика на внедренца до перехода к самой тесной фазе отношений – внедрению. Так что, если не учитывать идущий сейчас «мертвый» в плане новых проектов первый квартал года, можно сказать, что сказания мои максимально приближены к суровой реальности. Именно с точки зрения традиционного реального проекта по внедрению СЭД в Казахстане я и буду дальше вести речь, а не с точки зрения умника, слышавшего про PMBOK, PRINCE, MSF и прочих, безусловно, замечательных, но трудно применимых в наших степных условиях стандартов.  Это ведь там, где эти стандарты разрабатывались, среднестатистический водитель, двигаясь по безлюдной улице, дисциплинированно остановится перед линией «Стоп». У нас же, в большинстве случаев, водитель только газу поддаст. А это значит, что всегда в проекте найдется сотрудник, который посчитает, что правила писаны не для него и, что для того, чтобы было лучше, нужно сделать так, как он считает и как ему удобнее. К сожалению, зависимость между вероятностью попадания такого сотрудника и высотой занимаемого им положения обычно прямо пропорциональна. А компетенция – обратно. А посему придется внедренцу проявлять гибкость, которую в стандартах не опишешь.

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

Решаем организационные вопросы

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

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

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

На этом этапе (или еще ранее на стадии заключения договора) следует написать устав проекта хотя бы создать план-график работ. Если очень просто, то он может выглядеть вот так:

Или вот так:

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

Подготовительный этап

Внедренец начинает обследование. Как проводить обследование? В большинстве случаев четкой формализации этой процедуры нет, все зависит от конкретных обстоятельств.

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

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

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

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

Итак, специалисту по входящим внедренца представили. Начинается работа. Как? Для начала внедренец, конечно, должен рассказать специалисту что, собственно, от того требуется и зачем. Специалист должен представить и понять, что перемены неизбежны, и милые его сердцу входящие будут теперь находиться в окне СЭД. И лучше конструктивно поучаствовать в этом процессе, чтобы не оказаться потом один на один с ужасным интерфейсом непонятно как работающего «адского ящика».  И вот внедренец добросовестно пытается затащить специалиста по входящим на свою сторону, а тот, утирая пот со лба, заявляет, что у него очень много работы, и он не может больше уделить время на «ваш» проект. Что делать? Нет, бежать к руководителю проекта и жаловаться на специалиста не стоит. Раз уж руководитель не смог это сделать сразу, не факт, что во второй раз у него получится наставить сотрудника на путь истинный. Да и получить в результате этой попытки нелояльного обиженного специалиста по входящим также вряд ли входит в планы внедренца. И вот тут становится ясно, — какое качество самое главное для специалиста по внедрению СЭД, работающего непосредственно с заказчиком. Самое главное — не технические знания, умения и навыки, которые, безусловно, также важны. Но еще важнее хорошие коммуникационные способности и умение завоевывать расположение людей. Такой внедренец не отступится при первой неудаче, а начнет искать компромисс с нашим пресловутым специалистом по внедрению.  Войдет  в доверие, демонстрируя свое понимание его трудностей. Предложит варианты, как урегулировать ситуацию. В общем, даже без подручных средств, сделает так, что специалист сам начнет искать встречи с ним. А найдя, будет рад выложить все как на духу.

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