Внедрение программного продукта. Особенности работы бизнес-консультанта.

Труд — это отец удовольствия.

Стендаль.

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

Внедрение программного продукта с точки зрения бизнес-консультанта.

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

Еще раз: главное – решить поставленную бизнес-задачу!

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

Вы внедряете такое программное обеспечение, которое будет:

• Эффективно решать те задачи, которые поставил перед вами клиент.
• Поможет вам найти решение проблем, которые возникли в бизнесе.
• А также, естественно,

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

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

Например:

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

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

Почему это так важно? Правильная постановка цели помогает правильной реализации проекта. Вот как обычно выглядит типовой процесс внедрения ПО в большинстве случаев:

1. Получили перечень задач, которые нужно реализовать.
2. Доработали программный продукт с учетом пожеланий клиента.
3. Установили везде программу, настроили.
4. Провели краткое обучение.
5. Оставили инструкцию, написанную техническим языком и понятную, чаще всего, только системному администратору.

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

Что в итоге? Программное обеспечение внедрено, обучение проведено, акты выполненных работ подписаны, счета оплачены. Формально работа выполнена, и разработчики завершают сотрудничество. При этом внедренцам выгодно как можно быстрее закрыть проект и получить оплату. Сотрудникам клиента выгодно скорее закончить работу и спокойно перейти обратно на старую привычную версию программы. Единственный кто страдает – владелец компании. Он потерял деньги, но ничего не заработал.

Почему так происходит?

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

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

Свои бизнес-задачи разработчики, понятное дело, реализовали в полном объеме. А как компания будет работать далее при помощи их программного обеспечения, в большинстве случаев, им уже не интересно.

Другое дело – работа бизнес-консультанта. Здесь цели консультанта и клиента полностью совпадают, так как вы занимаетесь решением задачи заказчика, а не просто внедрением ПО. А потому и к процессу внедрения бизнес-консультант подходит немного не так, как разработчики.

Что такое внедрение?

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

(Википедия)

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

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

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

В Японии с древних времен обучают стрельбе из длинного лука Юми. Учителя одной из школ, классической, утверждают:
Для того чтобы добиться цели, необходимо концентрироваться не на самой цели, а на процессе, на каждом вашем действии.
Я считаю, что при внедрении программного обеспечения срабатывает тот же принцип. Вы один раз обозначили цель, а далее концентрируетесь на действиях, на каждом из этапов работы. И если вы правильно выполните каждое из действий, вы обязательно достигнете поставленной цели. Концентрируйтесь преимущественно не на том, что вы пытаетесь реализовать, а на том, как вы это делаете. Внимательно относитесь к каждому процессу, создавайте все условия для его реализации. И тогда вы действительно сможете прийти к цели.

Ошибки при внедрении.

Почему я так подробно остановился на этих понятиях – правильная постановка цели и концентрация на процессах? Я видел очень много ошибок построения процесса внедрения, причем, ошибок, которые приводили к печальным последствиям. От некоторых из этих ошибок, самых важных и распространенных, хочу вас предостеречь.

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

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

Для того чтобы избежать перечисленных ошибок, вам обязательно нужно донести до клиента простую мысль:
Здесь и сейчас вы выполняете уникальную работу, в уникальном окружении с уникальным результатом. А потому точно спрогнозировать все нюансы – просто невозможно!

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

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

В зависимости от сложности и объема предстоящей работы я чаще всего называю какие-то примерные сроки. Это могут быть 2 – 4 месяца или от полугода до 1,5 лет. Да, я не знаю точных сроков реализации проекта, как и не могу заранее точно сказать, как именно будет выглядеть результат моей работы. Но я точно знаю самое главное – это основную цель, а также, как именно реализовать каждый этап работы.
Т.е. я использую тот самый принцип, о котором уже упоминал в связи с японской стрельбой из лука Юми: сосредоточьтесь на каждом действии, на каждом этапе, качественно выполняйте каждое действие. И тогда вы обязательно придете к цели!
С чего начинается внедрение?

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

Также очень важно помнить, что ваш клиент – не айтишник, не продавец ПО, не консультант и не внедренец. Более того, скорей всего, для него внедрение программного продукта — это незнакомый или малознакомый процесс.

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

Кроме того, помните, что внедрение нового программного продукта, скорей всего, в его компании проводилось достаточно давно. Малый и средний бизнес очень часто пользуется одним программным обеспечением 7 – 10 лет. А потому к моменту начала вашей работы сотрудники компании либо уже забыли, как происходит внедрение программ, либо никогда не участвовали в этом процессе. А потому нужно понимать, что вы можете столкнуться со страхами, с неприятием, с другими сложностями.

Приведу пример. Когда-то я и сам слишком углублялся в технические нюансы и пытался пояснять чем, скажем, MailChimp отличается от 1С рассылки. Я рассказывал об API, о статистике, о числе отказов, а также о других технических параметрах. При этом клиенту, на самом деле, нужны были совсем другие данные. Ему было достаточно продемонстрировать пример письма и показать пример статистики, чтобы мы поняли друг друга и клиент понял выгоду для себя.

Говорите с клиентом с его точки зрения и на его языке!

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

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

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

Не в количестве знаний заключается образование, а в полном понимании и искусном применении всего того, что знаешь.

Гегель.

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

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

1. Постановка цели;
2. Ввод остатков в программу;
3. Обучение;
4. Доработка программы;
5. Написание документации;
6. Тестовая эксплуатация;
7. Промышленная эксплуатация.

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

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

Ввод остатков в программу

Ввод остатков в программу – это первый этап непосредственно вашей работы по внедрению программного продукта. И этот этап призван решить широкий перечень задач:

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

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

Обратите внимание! Я программистам техническое задание пишу, это удобно для всех. Сам же я не настаиваю на наличии ТЗ или брифов. Об этом я уже говорил здесь.

Уточняется необходимость в доработках. Этот пункт становится итогом предыдущих. С одной стороны, вы понимаете, требуются ли программные доработки, и если они нужны, то какие именно. С другой – ваш клиент также видит свои остатки в программе, может представить, как она будет работать, и внести дополнительные пожелания по доработкам.

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

Итак, техническое задание составлено. Вы передаете работу программисту, получаете результат, и можете переходить к обучению сотрудников компании. (Подробнее о доработках поговорим чуть позже).

Обучение

Существует 2 варианта обучения сотрудников работе с новым продуктом: это групповые занятия или обучение по 1-2 человека. Естественно, второй вариант дороже, но эффективнее. И здесь обычно решает руководитель, как его сотрудникам лучше учиться.

Как это происходит?

С групповым обучением, я думаю, все знакомы. Собирается группа сотрудников, чаще всего, это один отдел. Настраивается проектор или другой вариант большого экрана. А дальше я показываю и рассказываю, как в новой программе создавать нужные для работы этого отдела документы, как формировать отчеты и т.д. и т.п.
Намного интереснее обучение индивидуальное. Чаще всего я учу сотрудников компании попарно, т.к. это достаточно эффективно и позволяет экономить средства заказчика. Сначала я беру в работу одну пару, подробно все им рассказываю, показываю, отвечаю на вопросы. Далее, наступает очередь второй пары. И здесь мне ассистирует один из сотрудников, которые уже прошли обучение. Я читаю лекцию, рассказываю особенности работы, поясняю все нюансы. А сотрудник из первой пары показывает на практике, как выполнять то или иное действие. Также я говорю тем, кого обучаю, чтобы они не записывали мои слова, так как важно понять именно суть работы, а не заучивать алгоритм.

Таким образом, я добиваюсь сразу трех целей:

• Сотрудник, уже прошедший обучение, получает дополнительную учебную практику;
• Новая пара сотрудников видит, что за компьютером – их коллега. Таким образом, снимается возможный психологический барьер, они понимают, что ничего сложного в новой программе нет;
• Я снимаю с себя часть рутинной работы, за меня ее делает сотрудник клиента.

Далее, приходит очередь третьей пары. И здесь я беру в ассистенты сотрудника из второй пары и т.д.

Во время обучения очень важно наладить обратную связь

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

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

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

При обучении учитывайте гендерные различия сотрудников

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

Никакой снисходительности при обучении!

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

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

Вы в данном случае – не программист, даже если знаете эту работу в совершенстве. Вы – бизнес-консультант, который работает по проекту. А потому вы должны быть максимально эффективны, ведь вы ограничены во времени. И если к вам будет достаточно доброжелательное отношение среди сотрудников, работать с ними будет также проще на каждом из этапов вашей работы.

Напоминайте о том, что вы здесь – временно! Выполните проект и уйдете.

Достаточно часто, особенно, когда проект затягивается на несколько месяцев, сотрудники компании забывают, что вы здесь не навсегда. А потому стоит им напоминать, что вы в этой компании – не постоянный сотрудник, что вы уйдете, как только выполните свою работу. Это им помогает собраться и лучше воспринимать информацию.

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

Обучите своего преемника из числа сотрудников компании.

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

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

Почему это хорошо?

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

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

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

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

Доработка программы

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

Я противник таких методов работы. Бизнес-консультант должен представлять интересы клиента. У вас общие цели: решить поставленные бизнес-задачи. И вы должны быть лояльны к интересам клиента.

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

Также важно: не скрывайте от клиента, что вы – не программист, и доработками будет заниматься третий человек. На самом деле, вашему заказчику безразлично, кому платить деньги, вам или кому-то еще. Ему важно, чтобы сумма была адекватной, чтобы работа была выполнена качественно, и не требовала от него никаких лишних затрат времени и сил.
Я честно говорю клиенту: я не могу уметь все, а потому нанимаю для решения определенных задач узких специалистов. Также поясняю, что все вопросы я решу сам, от клиента потребуется только своевременная оплата и содействие.

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

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

Важно: бизнес-консультант, который работает с малым и средним бизнесом, должен быть неплохо знаком с программированием.

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

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

Схема работы должна быть такой:
Вы получаете задачу от клиента – корректируете ее – передаете программисту техзадание.
И обратно:
Вы получаете работу от программиста – тестируете ее – передаете клиенту.

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

Консультант не должен злоупотреблять доверием клиента.

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

Написание документации

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

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

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

Что я предлагаю своим клиентам?
Я создаю не Руководство пользователя, а Документацию для каждого отдела. Причем, эта документация охватывает не только работу с программным обеспечением, но и работу сотрудника в целом. А в разрезе работы с программным продуктом я наоборот, перечисляю только то, что нужно для работы конкретного отдела или даже сотрудника.
В комплект документации могут входить:

• Описание процесса работы отдела;
• План дня сотрудника;
• Должностная инструкция;
• Инструкция по работе с входящими / исходящими документами;
• Инструкция по работе с программным продуктом;
• Инструкции по работе с другими программами.

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

Лично я при создании подобной документации по максимум использую графику. Чаще всего, это графические нотации (IDEF 3, IDEF 0, Swim line и др.). Вы можете выбрать любой инструмент для создания таких графических инструкций, по своему вкусу. Главное – это результат. Кстати, избегайте упоминания нотаций, в которых вы будете делать описание бизнес-процесса, это информация не нужна клиенту.

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

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

Недостаточно только получить знания, надо найти им приложение. Недостаточно только желать, надо делать.

Гёте

Читателям моей серии статей о работе бизнес-консультанта в малом и среднем бизнесе, я хочу напомнить, что в прошлых статьях я рассказал:

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

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

В процессе внедрения нового программного продукта бизнес-консультант также создает обновленную схему работы подразделений компании:

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

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

Тестовая эксплуатация

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

Бе́та-тести́рование (англ. beta testing) — интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (Релизом) продукта на рынок, к массовому потребителю. В отличие от альфа-тестирования, проводимого силами штатных разработчиков или тестировщиков, бета-тестирование предполагает привлечение добровольцев из числа обычных будущих пользователей продукта, которым доступна упомянутая предварительная версия продукта (так называемая бета-версия)
Википедия

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

Факторы, необходимые для того, чтобы начать тестовую эксплуатацию:

1. Все остатки были уже перенесены.
2. Основные доработки выполнены.
3. Со стороны заказчика есть человек, который может отвечать за тестирование.

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

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

Тестовая эксплуатация может проводиться в несколько итераций

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

1. Проверили работу программы
2. Выявили ошибки
3. Исправили эти недочеты
4. Проверили работу повторно

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

Тестовую эксплуатацию можно производить одновременно с обучением

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

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

А для того, чтобы у пользователей во время совмещения обучения и тестирования не возникал негатив, важно выполнить два условия:

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

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

Документацию нужно готовить во время тестовой эксплуатации

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

Тестирование интеграций

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

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

Оптимальное решение – это собрать всех людей в одном помещении, и проводить совместное комплексное тестирование.

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

Еще один пример. Интегрируется 1С и Zoho CRM. При этом в Zoho создается контакт, в 1С – контактное лицо. Один из менеджеров по продажам создает карточку клиента в Zoho, другой – работает в среде 1С. На основе данных, полученных из Zoho, менеджер в 1С создает контактное лицо и партнера.

Если схема работы компании такова, что оба менеджера будут работать и в Zoho, и в 1С, то во время тестирования имеет смысл менять их местами.

Очень часто создание контактов и лидов разделено между разными сотрудниками. Но даже если этим занимается обычно один человек, на тестирование все равно лучше взять двоих и разделить эту работу. Так вы сможете точнее проверить систему, да и, как известно, «одна голова хорошо, а две – лучше».

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

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

Участие программиста на этапе тестирования

Скажу сразу и четко: программист в процессе тестирования участия не принимает. Совсем. Никогда. Он исправляет ошибки, занимается доработками. Но тестирование – это не его работа. Как говорит мой друг — Никогда не доверяй финального тестирования айтишнику.

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

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

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

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

«Подводные камни» тестирования

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

А потому, первое, что нужно сделать в каждом отделе, это назначить ответственного за тестирование.

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

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

Важно помнить самому и пояснять сотрудникам: вы, конечно, не являетесь их начальником, вы не имеете административных рычагов давления, но вы готовы довести проект до финала, не смотря ни на что.

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

Если вы сталкиваетесь с активным сопротивлением, можно в виде исключения привлечь руководителя. Далее обычно происходит следующее: руководитель лично подтверждает назначение конкретного человека ответственным лицом, в самых сложных случаях происходит беседа втроем: руководитель, вы и сотрудник. Но такие вещи должны быть редким исключением. Чаще всего даже в случае очень активного сопротивления сотрудников, после 1-2 подобных бесед отказы сотрудничать прекращаются сами по себе.

Бойкот: активный и пассивный

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

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

При этом именно бизнес-консультант оказывается в глазах сотрудников виновным во всех этих переменах и неприятностях. Меня на проектах часто считают серым кардиналом и, конечно же, не любят. Это нормально. В природе человека сопротивляться переменам. Помните, даже у китайцев есть такое проклятие: «Чтобы ты жил в эпоху перемен».

А потому если вы столкнулись с бойкотом, волноваться не нужно. Это самый обычный момент в вашей работе. Важно своевременно распознавать признаки бойкота и уметь эффективно решать эту проблем.

Итак, бойкот бывает двух типов:

1. активный
2. пассивный

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

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

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

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

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

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

Никогда не показывайте свою слабость или неуверенность, но признавайте свои ошибки!

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

Но ведь вы также живой человек, и можете ошибаться. И, конечно же, сотрудники компании обязательно заметят вашу ошибку и начнут задавать вопросы. Что делать? Никогда не врать и не оправдавываться. Спокойно и честно сказать: «Я ошибся». Помните, на этапе обучения я также вам говорил, не стесняйтесь говорить «я не знаю». Здесь ситуация аналогичная.

Да, вы – эксперт, да, вы много знаете и умеете, да, вы сумели разобраться в особенностях конкретного бизнеса настолько, что выявили недочеты и помогаете их исправить. Но при этом вы – живой человек. А человеку свойственно ошибаться. А потому идеальное решение в случае возникновения вопросов, это честно и спокойно признать ошибку, после чего исправить ее в сжатые сроки. Таким образом вы решите уничтожите проблему в зародыше.

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

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

Я лично не вижу ничего страшного в этом негативе. Это просто моя работа. И я хорошо помню, что все эмоции направлены не на меня, как на личность, а на процесс, который я принес и олицетворяю собой. А потому и эмоции воспринимаю также. Они потом поймут, оценят, а пока что им тоже сложно.

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

Завершение тестирования

Еще раз повторим этапы процесса тестирования:

1. Тестирование программистом. Перед тем, как сдавать вам работу, программист исправляет те ошибки, которые сумел выявить.
2. Тестирование вашими силами. Вы лично как можно подробнее тестируете работу программы до того, как установить очередной релиз у клиента.
3. Совместное тестирование с человеком, ответственным за проект. Вместе с этим лицом вы также подробно проверяете выполненную работу или проверяете качество доработок, убеждаетесь, что все работает.
4. Тестирование с непосредственными участниками процесса происходит в режиме, максимально приближенном к реальной работе. Люди выполняют свои обязанности в новой программной среде. Проверяют, насколько удобно и корректно работает система.

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

На этом этапе ни в коем случае: не давайте рядовым участникам процесса свои контакты!

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

Запуск проекта

Итак, тестирование прошло успешно и все с этим согласны. Что происходит дальше:

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

Если все эти пункты выполнены, можно запускать систему.

Важно понимать, что запуск – это еще не закрытый проект. Поясняйте это также клиенту. После запуска вы еще будете рядом в течении 1 – 2 недель в зависимости от сложности проекта.

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

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

Например, когда я запускал программный продукт на хлебозаводе, я спал по 3-4 часа в сутки в течении 3 ех дней. Я практически все время находился на предприятии. Программисты, которые также вели этот проект, могли отдыхать больше. Они просто должны были быть на связи для оперативного исправления возможных недочетов. А я почти круглые сутки проводил на проекте просто потому что хлебозавод работает круглосуточно, и надо было контролировать самые разные процессы в разное время.

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

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

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

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

Промышленная эксплуатация. Сопровождение

Если вы работали над проектом хорошо, то сопровождение практически сводится к нулю. Более того, лично я сопровождение провожу практически всегда удаленно.

Каким образом это происходит:

• Я обучаю одного или двух специалистов заказчика, как нужно описывать задачи. Для этого я использую программу jing. Если нужно, в задачу добавляется скриншот или видео с текстом описанием проблемы. После чего этот пакет информации отправляется мне.
• Все сопровождение идет через письменно, через систему багтрекинга. Я применяю для этого систему Redmine. Конечно, это не обязательно, просто мне лично так удобно.

Итак, если появляется потребность что-то доработать, специалисты со стороны клиента ставят в письменном виде мне задачу, я ее реализую. А в конце месяца (или 2 раза в месяц) отправляю отчет о проделанной работе и выставляю счет.

Еще раз напомню. Если вы хорошо выполнили работу по проекту, то таких доработок либо не будет вообще, либо они будут единичными. А потому сопровождение не приносит особой прибыли.

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

Как говорил один мой клиент о подобной работе: «Если я купил автомобиль, то я понимаю необходимость периодически ставить его на ТО, но все остальное время я должен просто ездить, причем, ездить без проблем и без постоянного присутствия механика у меня в машине на заднем сиденье».

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

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

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

Никогда не сжигайте мосты!

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

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

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

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

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