Не в количестве знаний заключается образование, а в полном понимании и искусном применении всего того, что знаешь.
Гегель.
Говорить о внедрении программного продукта можно очень долго, тема это обширная, а нюансов в работе бизнес-консультанта очень много. В статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть I я раскрыл только некоторые общие понятия, пояснил, чем работа бизнес-консультанта для малого и среднего бизнеса отличается от работы обычных внедренцев. Также я рассказал о тех базовых принципах, на которых я строю свою работу по внедрению программного обеспечения.
Сейчас я предлагаю перейти к подробному обсуждению процесса работы бизнес-консультанта при внедрении ПО. Лично я делю внедрение на следующие этапы:
- Постановка цели;
- Ввод остатков в программу;
- Обучение;
- Доработка программы;
- Написание документации;
- Тестовая эксплуатация;
- Промышленная эксплуатация.
Здесь я для наглядности выделил все этапы внедрения. Сразу скажу, что некоторые из них пересекаются друг с другом или происходят одновременно. Так, доработка программного продукта производится в несколько этапов, какие-то действия могут потребоваться после постановки цели. Также практически всегда требуются доработка и после ввода остатков, и после того, как на программу посмотрит клиент, и даже в процессе обучения. Но давайте по порядку.
Итак, о постановке цели мы говорили много и в этой, и в предыдущих статьях. Думаю, здесь вопросов возникнуть не должно. Но на всякий случай напомню: речь идет о бизнес-цели, под которую мы и выбираем программное обеспечение.
Ввод остатков в программу
Ввод остатков в программу – это первый этап непосредственно вашей работы по внедрению программного продукта. И этот этап призван решить широкий перечень задач:
1.Наглядность. Клиент сразу увидит, каким образом его данные будут отображаться в программе. Сможет уточнить свои пожелания и потребности. Подсказать какие-то решения, удобные для его бизнеса и его сотрудников.
2.Изучение нюансов работы. В процессе переноса остатков вы сможете выяснить очень много нюансов работы компании, разобраться, как работает какой из отделов, какие данные им нужны для работы, какие документы и отчеты чаще всего используются. Также вы на практике изучаете работу самого программного продукта (если не были знакомы с ним прежде). На основе этих данных вы сможете написать техническое задание для программиста.
Обратите внимание! Я программистам техническое задание пишу, это удобно для всех. Сам же я не настаиваю на наличии ТЗ или брифов. Об этом я уже говорил здесь.
Уточняется необходимость в доработках. Этот пункт становится итогом предыдущих. С одной стороны, вы понимаете, требуются ли программные доработки, и если они нужны, то какие именно. С другой – ваш клиент также видит свои остатки в программе, может представить, как она будет работать, и внести дополнительные пожелания по доработкам.
Например: Клиент в своей программе хранит специфическую информацию о своих покупателях. При переносе обнаруживается, что в новой программе нет подходящего справочника, т.е. эту информацию некуда переносить. Кроме того, работа с любой информацией не ограничивается хранением, необходимо как-то использовать эту информацию в новой программе. Значит, нужно разобраться, для чего эта информация была нужна, где она применялась, и соответствующим образом доработать новый программный продукт.
Итак, техническое задание составлено. Вы передаете работу программисту, получаете результат, и можете переходить к обучению сотрудников компании. (Подробнее о доработках поговорим чуть позже).
Обучение
Существует 2 варианта обучения сотрудников работе с новым продуктом: это групповые занятия или обучение по 1-2 человека. Естественно, второй вариант дороже, но эффективнее. И здесь обычно решает руководитель, как его сотрудникам лучше учиться.
Как это происходит?
С групповым обучением, я думаю, все знакомы. Собирается группа сотрудников, чаще всего, это один отдел. Настраивается проектор или другой вариант большого экрана. А дальше я показываю и рассказываю, как в новой программе создавать нужные для работы этого отдела документы, как формировать отчеты и т.д. и т.п.
Намного интереснее обучение индивидуальное. Чаще всего я учу сотрудников компании попарно, т.к. это достаточно эффективно и позволяет экономить средства заказчика. Сначала я беру в работу одну пару, подробно все им рассказываю, показываю, отвечаю на вопросы. Далее, наступает очередь второй пары. И здесь мне ассистирует один из сотрудников, которые уже прошли обучение. Я читаю лекцию, рассказываю особенности работы, поясняю все нюансы. А сотрудник из первой пары показывает на практике, как выполнять то или иное действие. Также я говорю тем, кого обучаю, чтобы они не записывали мои слова, так как важно понять именно суть работы, а не заучивать алгоритм.
Таким образом, я добиваюсь сразу трех целей:
- Сотрудник, уже прошедший обучение, получает дополнительную учебную практику;
- Новая пара сотрудников видит, что за компьютером – их коллега. Таким образом, снимается возможный психологический барьер, они понимают, что ничего сложного в новой программе нет;
- Я снимаю с себя часть рутинной работы, за меня ее делает сотрудник клиента.
Далее, приходит очередь третьей пары. И здесь я беру в ассистенты сотрудника из второй пары и т.д.
Во время обучения очень важно наладить обратную связь
В работе бизнес-консультанта процесс обучения должен работать в обе стороны. Вы обучаете сотрудников работе с программным продуктом, при этом обучаетесь сами особенностям работы компании. Прислушивайтесь к тому, что вам говорят и о чем спрашивают сотрудники. На основе их вопросов и потребностей вы сможете также составить список необходимых в программе доработок.
Общайтесь с сотрудниками компании как можно больше! Не бойтесь диалога и не бойтесь показаться некомпетентным. Вас уже пригласили в качестве эксперта. Вам уже доверяют решение сложных и важных для компании задач. А знать заранее все нюансы работы конкретной компании вы не можете.
А потому не бойтесь фразы «не знаю». Если вы затрудняетесь с ответом, берите таймаут, изучайте возможности настройки программы так, как нужно для работы. И при необходимости фиксируйте доработки.
При обучении учитывайте гендерные различия сотрудников
Почему-то об этом очень часто забывают, потому я и выделяю этот важный момент. С мужчинами и женщинами надо говорить немного по-разному. Есть фразы и стиль общения, который будет прекрасно принят мужским коллективом, но в женском вызовет неприятие и наоборот. Учитывайте эти различия, старайтесь общаться с учениками так, чтобы им было легко воспринимать информацию. Это поможет в процессе учебы.
Никакой снисходительности при обучении!
Эту ошибку достаточно часто совершают айтишники (программисты, сисадмины и т.д.). Мне сложно судить, почему это происходит, но практика показывает: именно представители этих профессий чаще всего при обучении пользователей переходят на снисходительный тон. Да, конечно, вы знаете эту программу намного лучше, чем те, кого вы обучаете. Вы также намного лучше понимаете бизнес-процессы, которые планируете внедрить. Но те, кого вы обучаете, также взрослые люди, эксперты в своем деле. А вас именно для того и пригласили, чтобы вы решили те проблемы, в которых вы – эксперт.
Я могу понять системного администратора, который работает в штате, не имеет никакой заинтересованности в результате обучения, а пояснять в очередной раз, как ему кажется, азы, очень скучно и давно надоело. Но сейчас я пишу о другой работе. О работе бизнес-консультанта.
Вы в данном случае – не программист, даже если знаете эту работу в совершенстве. Вы – бизнес-консультант, который работает по проекту. А потому вы должны быть максимально эффективны, ведь вы ограничены во времени. И если к вам будет достаточно доброжелательное отношение среди сотрудников, работать с ними будет также проще на каждом из этапов вашей работы.
Напоминайте о том, что вы здесь – временно! Выполните проект и уйдете.
Достаточно часто, особенно, когда проект затягивается на несколько месяцев, сотрудники компании забывают, что вы здесь не навсегда. А потому стоит им напоминать, что вы в этой компании – не постоянный сотрудник, что вы уйдете, как только выполните свою работу. Это им помогает собраться и лучше воспринимать информацию.
С одной стороны, люди понимают, что вы уйдете, и спрашивать будет не у кого. И стараются выучить максимум полезной информации. С другой, когда человек понимает, что еще немного, и все дополнительные сложности окончатся, ему психологически проще учиться и воспринимать что-то новое.
Обучите своего преемника из числа сотрудников компании.
Я очень часто использую этот прием. В общем, почти всегда. Из всех сотрудников выделяю 1-2 человек, и концентрирую на выбранном сотруднике (сотрудниках) максимум усилий. Я больше с ним общаюсь, более внимательно подхожу к его обучению, уделяю ему больше времени, могу даже проводить с ним отдельно бесплатные занятия. Таким образом, я готовлю одновременно союзника для себя и мою замену на будущее, на то время, когда я уйду из компании.
Всех одинаково обучить невозможно. Кто-то все равно будет отставать, что-то обязательно будет забываться. И человек, который в мое отсутствие сможет помочь, напомнить или подсказать, будет очень кстати после окончания проекта.
Почему это хорошо?
Клиент видит, что он не будет зависеть от меня после окончания сотрудничества. Он понимает, что у него будет собственный сотрудник, который прекрасно знает программное обеспечение (почти как я) и в случае чего, всегда сможет помочь.
Сотрудник получает больше знаний и опыта, становится более ценным кадром для компании. Конечно, это для него – плюс.
Другие сотрудники понимают, что у них есть кто-то свой, коллега, к которому всегда можно обратиться за советом и помощью. Я – бизнес-консультант, мое время стоит денег, и сотрудники любой компании об этом постоянно помнят. А потому они часто стесняются задавать мне какие-то вопросы повторно, а своего коллегу переспросить всегда смогут.
Казалось бы, я лишаю себя дополнительного заработка. Но получить небольшую доплату за то, что вы повторно ответили на один и тот же вопрос, не столь интересно, как получить благодарного клиента, который вам доверяет, готов работать в будущем, и даже рекомендует вас своим знакомым.
Доработка программы
Как я уже писал выше, доработки проводятся в несколько этапов по мере необходимости. При этом очень важно выполнять только те действия, которые действительно нужны. Иногда бывает, что программист создает новый отчет там, где можно было бы настроить стандартный, просто потому, что так проще для специалиста и, понятное дело, дороже.
Я противник таких методов работы. Бизнес-консультант должен представлять интересы клиента. У вас общие цели: решить поставленные бизнес-задачи. И вы должны быть лояльны к интересам клиента.
А потому если в программе уже тем или иным образом реализован нужный клиенту отчет или документ, настройте и применяйте его. Единственное исключение из этого правила: клиент настаивает на определенном варианте реализации, при этом он поставлен в известность обо всех возможностях программы.
Также важно: не скрывайте от клиента, что вы – не программист, и доработками будет заниматься третий человек. На самом деле, вашему заказчику безразлично, кому платить деньги, вам или кому-то еще. Ему важно, чтобы сумма была адекватной, чтобы работа была выполнена качественно, и не требовала от него никаких лишних затрат времени и сил.
Я честно говорю клиенту: я не могу уметь все, а потому нанимаю для решения определенных задач узких специалистов. Также поясняю, что все вопросы я решу сам, от клиента потребуется только своевременная оплата и содействие.
Важно: обязательно перед этапом доработки нужно составить списки отчетов, которыми пользуются сотрудники при работе с текущим программным продуктом.
Все эти отчеты должны присутствовать в новой программе, причем, доступ к ним должен быть простым и удобным.
А программиста необходимо подключить к работе над программным продуктом как можно раньше, сразу же, как только у вас появятся первые задачи для доработки. Кроме того, старайтесь сделать так, чтобы до конца проекта работал один и тот же человек.
Важно: бизнес-консультант, который работает с малым и средним бизнесом, должен быть неплохо знаком с программированием.
Лично я достаточно хорошо знаю 1С-программирование, также знаком с веб-программированием, в частности, работаю с Drupal и с другими CMS. В процессе работы с программистом вы должны четко поставить задачу специалисту, а потом грамотно протестировать выполненную работу перед тем, как ее принять и показать клиенту.
Никогда не давайте прямой доступ программисту к вашему клиенту!
Даже если очень хочется, не стоит давать прямой доступ к вашему клиенту никому из специалистов, с которыми вы работаете. Клиент все равно не сумеет поставить задачу также четко, как это сделаете вы. А программисту будет спокойнее работать, если вы избавите его от любого возможного негатива.
Схема работы должна быть такой:
Вы получаете задачу от клиента – корректируете ее – передаете программисту техзадание.
И обратно:
Вы получаете работу от программиста – тестируете ее – передаете клиенту.
Достаточно часто клиент при обсуждении выполненных программистом доработок, выдает какие-то эмоции, в том числе, негативные. Ваша задача – принять весь негатив на себя, разобраться, что именно не понравилось и почему, передать в корректном виде требования по доработке программисту. Таким образом, программист избавлен от негатива и может спокойно работать, а клиент получает то, что ему нужно. И также доволен.
Консультант не должен злоупотреблять доверием клиента.
Консультант достаточно многое решает самостоятельно, «за клиента», но у него должна быть своя этика. Вы убеждаете клиента в правильности вашего решения, и он с вами соглашается. Но вы при этом также должны быть уверены, что ваше решение – оптимально. Помните, что нанял вас в качестве эксперта, который сможет эффективно решить поставленную бизнес-задачу. А потому у вас с клиентом – общие цели, и вы должны всегда очень внимательно относиться к интересам клиента, отстаивать их, искать лучшие продукты и методы, и, в результате, наилучшим образом решать поставленную задачу.
Написание документации
Итак, ваша программа работает так, как это нужно, сотрудники прошли обучение и готовы пользоваться новым продуктом даже без вашей помощи. Остается написать документацию.
И здесь также есть важная особенность. В отличии от разработчиков ПО, вы – бизнес-консультант. А потому и документация, которую вы будете писать для вашего клиента, несколько отличается от обычной инструкции по работе с программным продуктом.
Почему так редко используются обычные Руководства пользователя? В них много информации, которая не нужна большинству сотрудников. Найти то, что нужно здесь и сейчас, обычно достаточно сложно. В результате об этих Инструкциях вспоминают только в самых крайних случаях.
Что я предлагаю своим клиентам?
Я создаю не Руководство пользователя, а Документацию для каждого отдела. Причем, эта документация охватывает не только работу с программным обеспечением, но и работу сотрудника в целом. А в разрезе работы с программным продуктом я наоборот, перечисляю только то, что нужно для работы конкретного отдела или даже сотрудника.
В комплект документации могут входить:
- Описание процесса работы отдела;
- План дня сотрудника;
- Должностная инструкция;
- Инструкция по работе с входящими / исходящими документами;
- Инструкция по работе с программным продуктом;
- Инструкции по работе с другими программами.
В общем, вы создаете такой пакет документов, который сможет помочь новому сотруднику быстро разобраться с работой отдела, должностными обязанностями и приступить к работе без длительной стажировки и помощи увольняющегося коллеги.
Лично я при создании подобной документации по максимум использую графику. Чаще всего, это графические нотации (IDEF 3, IDEF 0, Swim line и др.). Вы можете выбрать любой инструмент для создания таких графических инструкций, по своему вкусу. Главное – это результат. Кстати, избегайте упоминания нотаций, в которых вы будете делать описание бизнес-процесса, это информация не нужна клиенту.
Почему я предпочитаю графику? Возможно, вы слышали фразу, что одна картинка стоит тысячи слов. В этом все дело. Графика лучше воспринимается, ее легче запомнить. А потому любые рабочие процессы, которые возможно, составляйте в графическом виде. Используйте при этом стрелки, пиктограммы, но старайтесь не перегружать описание деталями.
Надеюсь, что я сумел в этой статье раскрыть различные нюансы работы бизнес-консультанта по внедрению программного продукта. Этапы переноса остатков, доработок и обучения очень важны для успешной работы. Потому я остановился на них настолько подробно. В следующей статье я расскажу вам о двух последних этапах, тестовой и промышленной эксплуатации программного обеспечения, а также о том, что происходит после окончания непосредственно внедрения.
