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

Часть I

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

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

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

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

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

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

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

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

‍Почему так происходит? Разработчики не заинтересованы в дальнейшем сотрудничестве с клиентом, а потому обучение производится исключительно формально. Программный продукт действительно не удовлетворяет все потребности компании, но понять это удалось только после внедрения. А, как известно, за доработку после подписания акта выполненных работ, оплата производится отдельно. Сотрудники не увидели для себя никаких преимуществ от внедрения нового программного продукта, при этом постоянно испытывали трудности при выполнении привычных операций в новой системе, в результате саботировали дальнейшую работу с новой программой. Можно и дальше перечислять причины, почему тот или иной продукт оказался невостребованным. На самом деле причина здесь одна: Люди, которые занимались внедрением, не были заинтересованы в решении определенных бизнес-задач клиента. Свои бизнес-задачи разработчики, понятное дело, реализовали в полном объеме. А как компания будет работать далее при помощи их программного обеспечения, в большинстве случаев, им уже не интересно. Другое дело – работа бизнес-консультанта. Здесь цели консультанта и клиента полностью совпадают, так как вы занимаетесь решением задачи заказчика, а не просто внедрением ПО. А потому и к процессу внедрения бизнес-консультант подходит немного не так, как разработчики.

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

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

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

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

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

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

Вы никогда до этого не работали с этой компанией, а потому не можете предсказать все нюансы. Сотрудники компании в большинстве случаев также никогда раньше не проходили обучение работе с данным программным продуктом. И никто никогда не использовал результаты той работы, которую вы собираетесь провести. Конечно, вы умеете работать с малым и средним бизнесом, у вас имеется опыт успешной реализации других проектов. Также вы знаете предложенный вами программный продукт и, скорей всего, можете похвастаться успешным опытом его внедрения. Но все это было – для других клиентов, у которых другие потребности, особенности построения бизнеса, у них работают другие люди и т.д. А здесь и сейчас реализуется индивидуальный проект. А потому и предсказать точно, к чему вы с клиентом придете в финале, и сколько времени займет работа, невозможно. В зависимости от сложности и объема предстоящей работы я чаще всего называю какие-то примерные сроки. Это могут быть 2 – 4 месяца или от полугода до 1,5 лет. Да, я не знаю точных сроков реализации проекта, как и не могу заранее точно сказать, как именно будет выглядеть результат моей работы. Но я точно знаю самое главное – это основную цель, а также, как именно реализовать каждый этап работы. Т.е. я использую тот самый принцип, о котором уже упоминал в связи с японской стрельбой из лука Юми: сосредоточьтесь на каждом действии, на каждом этапе, качественно выполняйте каждое действие. И тогда вы обязательно придете к цели! С чего начинается внедрение? Прежде чем начинать саму работу, очень важно донести до клиента ту философию, о которой я говорил выше. Вы можете использовать для этого разные слова, делать акцент на тех моментах, которые, по вашему мнению, будут лучше приняты вашим клиентом. В каких-то определенных моментах можно взять на себя даже достаточно жесткие обязательства. Но это – частности. А, в общем, клиент обязательно должен понимать: работа может длиться достаточно долго, и в процессе могут быть какие-то перемены. Это нормальный рабочий процесс, все идет по плану и обязательно будет нужный результат. Если вы все правильно донесли до клиента, то в будущем с его стороны не возникнет никакого негатива или претензий в отношении сроков или каких-то этапов внедрения программы. Он предупрежден обо всех нюансах работы. Также очень важно помнить, что ваш клиент – не айтишник, не продавец ПО, не консультант и не внедренец. Более того, скорей всего, для него внедрение программного продукта — это незнакомый или малознакомый процесс. Ваш клиент хорошо знает свою работу, в этом он – эксперт. А большая часть ваших пояснений, техническая терминология и перечень необходимых шагов для него все равно не понятны. А потому и не нужны. Поясняйте цели, поясняйте, какую задачу вы решите в результате. А о самом процессе нужно говорить как можно меньше и акцентировать внимание, прежде всего, на тех действиях, для реализации которых потребуется участие клиента. Кроме того, помните, что внедрение нового программного продукта, скорей всего, в его компании проводилось достаточно давно. Малый и средний бизнес очень часто пользуется одним программным обеспечением 7 – 10 лет. А потому к моменту начала вашей работы сотрудники компании либо уже забыли, как происходит внедрение программ, либо никогда не участвовали в этом процессе. А потому нужно понимать, что вы можете столкнуться со страхами, с неприятием, с другими сложностями. Приведу пример. Когда-то я и сам слишком углублялся в технические нюансы и пытался пояснять чем, скажем, MailChimp отличается от 1С рассылки. Я рассказывал об API, о статистике, о числе отказов, а также о других технических параметрах. При этом клиенту, на самом деле, нужны были совсем другие данные. Ему было достаточно продемонстрировать пример письма и показать пример статистики, чтобы мы поняли друг друга и клиент понял выгоду для себя.

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

Часть II

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

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

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

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

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

Ввод остатков в программу – это первый этап непосредственно вашей работы по внедрению программного продукта. И этот этап призван решить широкий перечень задач: 1.Наглядность. Клиент сразу увидит, каким образом его данные будут отображаться в программе. Сможет уточнить свои пожелания и потребности. Подсказать какие-то решения, удобные для его бизнеса и его сотрудников. 2.Изучение нюансов работы. В процессе переноса остатков вы сможете выяснить очень много нюансов работы компании, разобраться, как работает какой из отделов, какие данные им нужны для работы, какие документы и отчеты чаще всего используются. Также вы на практике изучаете работу самого программного продукта (если не были знакомы с ним прежде). На основе этих данных вы сможете написать техническое задание для программиста. Обратите внимание! Я программистам техническое задание пишу, это удобно для всех. Сам же я не настаиваю на наличии ТЗ или брифов. Об этом я уже говорил здесь. Уточняется необходимость в доработках. Этот пункт становится итогом предыдущих. С одной стороны, вы понимаете, требуются ли программные доработки, и если они нужны, то какие именно. С другой – ваш клиент также видит свои остатки в программе, может представить, как она будет работать, и внести дополнительные пожелания по доработкам. Например: Клиент в своей программе хранит специфическую информацию о своих покупателях. При переносе обнаруживается, что в новой программе нет подходящего справочника, т.е. эту информацию некуда переносить. Кроме того, работа с любой информацией не ограничивается хранением, необходимо как-то использовать эту информацию в новой программе. Значит, нужно разобраться, для чего эта информация была нужна, где она применялась, и соответствующим образом доработать новый программный продукт. Итак, техническое задание составлено. Вы передаете работу программисту, получаете результат, и можете переходить к обучению сотрудников компании. (Подробнее о доработках поговорим чуть позже).

Обучение

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

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

Далее, приходит очередь третьей пары. И здесь я беру в ассистенты сотрудника из второй пары и т.д. Во время обучения очень важно наладить обратную связь В работе бизнес-консультанта процесс обучения должен работать в обе стороны. Вы обучаете сотрудников работе с программным продуктом, при этом обучаетесь сами особенностям работы компании. Прислушивайтесь к тому, что вам говорят и о чем спрашивают сотрудники. На основе их вопросов и потребностей вы сможете также составить список необходимых в программе доработок. Общайтесь с сотрудниками компании как можно больше! Не бойтесь диалога и не бойтесь показаться некомпетентным. Вас уже пригласили в качестве эксперта. Вам уже доверяют решение сложных и важных для компании задач. А знать заранее все нюансы работы конкретной компании вы не можете. А потому не бойтесь фразы «не знаю». Если вы затрудняетесь с ответом, берите таймаут, изучайте возможности настройки программы так, как нужно для работы. И при необходимости фиксируйте доработки. При обучении учитывайте гендерные различия сотрудников Почему-то об этом очень часто забывают, потому я и выделяю этот важный момент. С мужчинами и женщинами надо говорить немного по-разному. Есть фразы и стиль общения, который будет прекрасно принят мужским коллективом, но в женском вызовет неприятие и наоборот. Учитывайте эти различия, старайтесь общаться с учениками так, чтобы им было легко воспринимать информацию. Это поможет в процессе учебы. Никакой снисходительности при обучении! Эту ошибку достаточно часто совершают айтишники (программисты, сисадмины и т.д.). Мне сложно судить, почему это происходит, но практика показывает: именно представители этих профессий чаще всего при обучении пользователей переходят на снисходительный тон. Да, конечно, вы знаете эту программу намного лучше, чем те, кого вы обучаете. Вы также намного лучше понимаете бизнес-процессы, которые планируете внедрить. Но те, кого вы обучаете, также взрослые люди, эксперты в своем деле. А вас именно для того и пригласили, чтобы вы решили те проблемы, в которых вы – эксперт. Я могу понять системного администратора, который работает в штате, не имеет никакой заинтересованности в результате обучения, а пояснять в очередной раз, как ему кажется, азы, очень скучно и давно надоело. Но сейчас я пишу о другой работе. О работе бизнес-консультанта. Вы в данном случае – не программист, даже если знаете эту работу в совершенстве. Вы – бизнес-консультант, который работает по проекту. А потому вы должны быть максимально эффективны, ведь вы ограничены во времени. И если к вам будет достаточно доброжелательное отношение среди сотрудников, работать с ними будет также проще на каждом из этапов вашей работы. Напоминайте о том, что вы здесь – временно! Выполните проект и уйдете. Достаточно часто, особенно, когда проект затягивается на несколько месяцев, сотрудники компании забывают, что вы здесь не навсегда. А потому стоит им напоминать, что вы в этой компании – не постоянный сотрудник, что вы уйдете, как только выполните свою работу. Это им помогает собраться и лучше воспринимать информацию. С одной стороны, люди понимают, что вы уйдете, и спрашивать будет не у кого. И стараются выучить максимум полезной информации. С другой, когда человек понимает, что еще немного, и все дополнительные сложности окончатся, ему психологически проще учиться и воспринимать что-то новое. Обучите своего преемника из числа сотрудников компании. Я очень часто использую этот прием. В общем, почти всегда. Из всех сотрудников выделяю 1-2 человек, и концентрирую на выбранном сотруднике (сотрудниках) максимум усилий. Я больше с ним общаюсь, более внимательно подхожу к его обучению, уделяю ему больше времени, могу даже проводить с ним отдельно бесплатные занятия. Таким образом, я готовлю одновременно союзника для себя и мою замену на будущее, на то время, когда я уйду из компании. Всех одинаково обучить невозможно. Кто-то все равно будет отставать, что-то обязательно будет забываться. И человек, который в мое отсутствие сможет помочь, напомнить или подсказать, будет очень кстати после окончания проекта. Почему это хорошо? Клиент видит, что он не будет зависеть от меня после окончания сотрудничества. Он понимает, что у него будет собственный сотрудник, который прекрасно знает программное обеспечение (почти как я) и в случае чего, всегда сможет помочь. Сотрудник получает больше знаний и опыта, становится более ценным кадром для компании. Конечно, это для него – плюс. Другие сотрудники понимают, что у них есть кто-то свой, коллега, к которому всегда можно обратиться за советом и помощью. Я – бизнес-консультант, мое время стоит денег, и сотрудники любой компании об этом постоянно помнят. А потому они часто стесняются задавать мне какие-то вопросы повторно, а своего коллегу переспросить всегда смогут. Казалось бы, я лишаю себя дополнительного заработка. Но получить небольшую доплату за то, что вы повторно ответили на один и тот же вопрос, не столь интересно, как получить благодарного клиента, который вам доверяет, готов работать в будущем, и даже рекомендует вас своим знакомым.

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

Как я уже писал выше, доработки проводятся в несколько этапов по мере необходимости. При этом очень важно выполнять только те действия, которые действительно нужны. Иногда бывает, что программист создает новый отчет там, где можно было бы настроить стандартный, просто потому, что так проще для специалиста и, понятное дело, дороже. Я противник таких методов работы. Бизнес-консультант должен представлять интересы клиента. У вас общие цели: решить поставленные бизнес-задачи. И вы должны быть лояльны к интересам клиента. А потому если в программе уже тем или иным образом реализован нужный клиенту отчет или документ, настройте и применяйте его. Единственное исключение из этого правила: клиент настаивает на определенном варианте реализации, при этом он поставлен в известность обо всех возможностях программы. Также важно: не скрывайте от клиента, что вы – не программист, и доработками будет заниматься третий человек. На самом деле, вашему заказчику безразлично, кому платить деньги, вам или кому-то еще. Ему важно, чтобы сумма была адекватной, чтобы работа была выполнена качественно, и не требовала от него никаких лишних затрат времени и сил. Я честно говорю клиенту: я не могу уметь все, а потому нанимаю для решения определенных задач узких специалистов. Также поясняю, что все вопросы я решу сам, от клиента потребуется только своевременная оплата и содействие. Важно: обязательно перед этапом доработки нужно составить списки отчетов, которыми пользуются сотрудники при работе с текущим программным продуктом. Все эти отчеты должны присутствовать в новой программе, причем, доступ к ним должен быть простым и удобным. А программиста необходимо подключить к работе над программным продуктом как можно раньше, сразу же, как только у вас появятся первые задачи для доработки. Кроме того, старайтесь сделать так, чтобы до конца проекта работал один и тот же человек. Важно: бизнес-консультант, который работает с малым и средним бизнесом, должен быть неплохо знаком с программированием. Лично я достаточно хорошо знаю 1С-программирование, также знаком с веб-программированием, в частности, работаю с Drupal и с другими CMS. В процессе работы с программистом вы должны четко поставить задачу специалисту, а потом грамотно протестировать выполненную работу перед тем, как ее принять и показать клиенту. Никогда не давайте прямой доступ программисту к вашему клиенту! Даже если очень хочется, не стоит давать прямой доступ к вашему клиенту никому из специалистов, с которыми вы работаете. Клиент все равно не сумеет поставить задачу также четко, как это сделаете вы. А программисту будет спокойнее работать, если вы избавите его от любого возможного негатива. Схема работы должна быть такой: Вы получаете задачу от клиента – корректируете ее – передаете программисту техзадание. И обратно: Вы получаете работу от программиста – тестируете ее – передаете клиенту. Достаточно часто клиент при обсуждении выполненных программистом доработок, выдает какие-то эмоции, в том числе, негативные. Ваша задача – принять весь негатив на себя, разобраться, что именно не понравилось и почему, передать в корректном виде требования по доработке программисту. Таким образом, программист избавлен от негатива и может спокойно работать, а клиент получает то, что ему нужно. И также доволен. Консультант не должен злоупотреблять доверием клиента. Консультант достаточно многое решает самостоятельно, «за клиента», но у него должна быть своя этика. Вы убеждаете клиента в правильности вашего решения, и он с вами соглашается. Но вы при этом также должны быть уверены, что ваше решение – оптимально. Помните, что нанял вас в качестве эксперта, который сможет эффективно решить поставленную бизнес-задачу. А потому у вас с клиентом – общие цели, и вы должны всегда очень внимательно относиться к интересам клиента, отстаивать их, искать лучшие продукты и методы, и, в результате, наилучшим образом решать поставленную задачу.

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

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

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

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

Часть III

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

Гёте

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

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

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

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

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

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

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

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

Бе́та-тести́рование (англ. 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 раза в месяц) отправляю отчет о проделанной работе и выставляю счет. Еще раз напомню. Если вы хорошо выполнили работу по проекту, то таких доработок либо не будет вообще, либо они будут единичными. А потому сопровождение не приносит особой прибыли. С другой стороны, и это очень важно, сопровождение и не должно быть особо прибыльным процессом. Если вы ориентируетесь на постоянное сопровождение, то вы просто плохо выполнили свою работу. Как говорил один мой клиент о подобной работе: «Если я купил автомобиль, то я понимаю необходимость периодически ставить его на ТО, но все остальное время я должен просто ездить, причем, ездить без проблем и без постоянного присутствия механика у меня в машине на заднем сиденье». Так и сопровождение: если работа выполнена хорошо, то какое-то техническое обслуживание, какие-то доработки могут быть нужны изредка. И не волнуйтесь о том, что вы недополучите какую-то прибыль. Вы получите даже больше благодаря таким факторам:

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

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

Построение процессной модели при внедрении программного обеспечения

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

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

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

«Подводные камни» планирования в сфере IT

Любой план достижения цели должен учитывать такие факторы:

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

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

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

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

При планировании проекта в сфере IT необходимо:

1. Изучить особенности и потребности заказчика;
2. Четко понять поставленную задачу и учесть все пожелания;
3. Согласовать с заказчиком выбранные решения.

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

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

Компьютерная информационная система – это идея, выраженная посредством языка программирования.

 

Подробное описание и обоснование такого определения я давал в статье «Что такое компьютерная информационная система». Для лучшего понимания рекомендую ознакомиться всем, кто еще ее не читал.

Идея и выбор программных продуктов

Первое и наиболее очевидное, что нужно понимать: чтобы выбранный или созданный под заказ программный продукт соответствовали вашей идее, необходимо сочетание двух факторов:

1. Наличие самой идеи;
2. Ее внятное и однозначное описание для других участников проекта.

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

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

Для описания бизнеса или выполнения какой-либо задачи могут применяться два подхода – процессный и функциональный. Об их отличиях и особенностях я также уже подробно писал в статье «Моделирование бизнеса. Основные подходы».

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

Как это делают:

1. Создается графическая нотация (описание) бизнес процесса. Я рекомендую использовать формат BPMN 2.0 как наиболее продвинутый и проработанный инструмент, применение которого снижает вероятность ошибок и неоднозначных решений.
2. Идею, выраженную в виде BPMN нотации, обсуждают с заинтересованными сторонами (заказчики, пользователи, в некоторых случаях – разработчики).
3. Под согласованную идею выбирают программное обеспечение либо принимают решение о написании программного продукта с нуля.
4. Составляется план работ с учетом выбранных инструментов, решений, подробно разработанной идеи (BPMN нотации).

Как создается BPMN модель

Для успешного составления BPM нотации человек должен обладать определенными знаниями:

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

При сотрудничестве с бизнесом или некоммерческими организациями процесс сотрудничества строится следующим образом:

1. Общая постановка задачи – формулируется руководителем компании;
2. Уточнение этапов работы и особенностей реализации – руководители и сотрудники подразделений, которые будут работать с программным продуктом.

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

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

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

Выбор программного продукта

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

В наше время для коммерческих и некоммерческих организаций крайне редко приходится писать программные решения «с нуля». Это дорого и долго. Тем более, что для большинства идей существуют готовые (типовые) решения, которые достаточно настроить и/или немного доработать.

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

Например, идея звучит так: «нужна автоматизация работы отдела продаж».

Этап 1. Для реализации лучше всего подходит CRM-система. Эти программные решения разрабатываются специально для отделов продаж.

Этап 2. Из всех существующих CRM нужно выбрать те, функционал которых максимально подходит под выбранный алгоритм работы (реализацию идею).

Этап 3. Выбор из составленного списка подходящих CRM заключается в изучении их дополнительного функционала: готовых решений для интеграции с другими программными продуктами, наличие встроенных полезных для идеи инструментов, соотношение цены/качества.

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

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

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

Преимущества процессного подхода

1. Человек мыслит последовательно. Одновременно продумывать несколько разных действий и охватывать несколько задач или направлений – крайне сложно. Человек мыслит шаг за шагом, решая одну за другой задачи по мере их поступления. А потому вариант воплощения идеи в виде последовательности действий – наиболее подходящий. Он позволяет продумать все детали и не пропустить ничего важного.
2. Однозначность решения и простота согласования участниками проекта. Графические нотации читаются просто, они понятны интуитивно руководителю компании-заказчика, близки к блок-схемам алгоритмизации, а потому удобны разработчикам. В итоге, их просто согласовать, а при реализации практически не возникает разночтений.
3. Формат BPMN поможет избежать ошибок. Сама среда разработки графических нотаций и простота отображения помогают вовремя заметить большинство ошибок, избежать логических противоречий и «незавершенных» процессов.

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

Выбор программного продукта для клиента. Сбор требований

"Даже самый длинный путь начинается с маленького первого шага" (Лао-Цзы)

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

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

1. Разобраться во всех важных нюансах работы конкретной компании
2. Создать благожелательные и доверительные отношения с клиентом

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

С чего начинать?

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

Добивайтесь личной встречи с руководителем

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

О чем говорить при первой встрече?

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

1. Выбирать программное обеспечения будете именно вы. И с вашей помощью компания получит не просто красивую систему, но эффективный инструмент для решения поставленных задач. Более того, в отличии от продавцов конкретного программного обеспечения, вы не заинтересованы в выборе какого-то конкретного продукта, а потому ваш выбор будет действительно объективным.
2. Расположите клиента к себе. Покажите, что вы обладаете достаточной гибкостью и готовы к диалогу. А потому учтите обязательно предпочтения клиента. Если существует какое-то программное обеспечение, созданное специально для этого вида бизнеса, обязательно начните изучение программных продуктов с него. Ваш клиент должен видеть, что вы – эксперт в своей области. Конечно, вы можете не знать всех нюансов его бизнеса (ведь вы не можете знать всего!), а потому всегда готовы прислушаться к советам и мнению соответствующих специалистов. Но в целом вашей компетенции и личных качеств хватит на то, чтобы разобраться даже с новой для вас отраслью и найти оптимальное решение проблемы.

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

Сбор сведений и общение с сотрудниками

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

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

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

1. Общение с контактным лицом.
2. Обязательное общение с руководителем (владельцем бизнеса).
3. Интервью с самыми разными сотрудниками, начиная от контактного лица и оканчивая представителями различных отделов, магазинов, складов.
4. Выбор программного продукта и презентация его руководству.

Как правильно выбирать?

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

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

Если все нужные сведения у вас есть, можно перейти непосредственно к выбору программного продукта. Помните, что на этом этапе бизнес-консультант должен быть нейтрален. Забудьте о том, что вы 10 лет занимались 1С и по привычке прикидываете решения на этой платформе. Посмотрите на самые разные варианты и выберите тот, который действительно сможет решить поставленную задачу с минимальными вложениями и доработками (а лучше вообще без последних). Лично я выбираю так. После того, как четко формулирую для себя задачу и понимаю, какие особенности работы важно учитывать, первым делом перебираю известные мне программные продукты. Возможно, решение найдется среди них. Если нет – приходится пользоваться поиском в Интернете, рассматривать разнообразные предложения готового программного обеспечения, изучаю различные варианты. Ну, а если и этот путь не дал результата, значит, нужно писать программное решение под заказ. При этом не забывайте о навыках персонала и предпочтениях руководителя. Если есть возможность выбрать продукт, который не только решит задачу, но и понравится клиенту, то есть смысл выбрать именно такое решение. Не усложняйте себе и людям жизнь без необходимости. Что дальше? А дальше вам понадобится презентовать свое решение руководству компании, убедить их в вашей компетентности и в том, что именно выбранный вами программный продукт сможет максимально эффективно решить все задачи. К этой встрече нужно готовиться всерьез, ведь продавать вы будете, в первую очередь, не программу, а себя, свою компетентность, свои навыки и знания. И если на этом этапе клиент начнет вам доверять, можно считать, что сотрудничество состоялось, в дальнейшем он будет также без проблем принимать ваши предложения, и ваша работа, как бизнес-консультанта для этой компании, будет идти плодотворно и взаимовыгодно. Тема встречи и презентации продукта достаточно объемна, а сама встреча является очень важной, практически ключевой для вашего сотрудничества, а потому поговорим о ней отдельно в следующей статье.

Техническое задание на автоматизацию. Каким оно должно быть, состав и технологии создания

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

Почему так важно правильно начинать? Только одно начало ведет только к одному концу.

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

Согласно диалектике результат, например, внедренная IT-система (важно, не просто реализованная, но внедренная!), это – развернутое начало.

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

Все начинается с идеи

В начале было слово....

В начале создания любого программного обеспечения нужно слово. Это бриф. Иначе говоря – идея. Когда мы хотим создать любое программное обеспечение, сначала нужно сформировать идею.

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

Для примера, идеей может быть: «Разработать IT-систему для контроля взаиморасчетов» или «Разработать IT-систему для автоматизации продаж». Также это может быть описание процесса, например, в таком виде:

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

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

Как формулировать идею

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

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

Пример (отсюда)

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

А что если мы хотели совсем не то, что в итоге получилось?

Этот вопрос-возражение нередко задают заказчики. Обычно он звучит так:

“Мы хотели CRM-систему, а написали, что нужна ERP” или “Нам нужна была CMS для сайта, а мы написали CRM”.

Ошибки в терминологии – распространенная проблема. А в сфере IT терминология сложна и очень важна. Потому лично я посвящаю правильной терминологии множество публикаций.

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

Ну, а если в процессе согласований не возникло каких-то сложностей, и вы получили результат, который помогает решать поставленные задачи, скорей всего, вы просто ошибочно использовали термины. И когда говорили “CRM” на самом деле имели в виду ERP или наоборот.

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

Графическое описание процесса

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

О том как описать процесс вы можете почитать здесь

Почему так важен процесс? Подробно об этом вы можете почитать в моей статье «Бизнес-моделирование», где описаны основные подходы. Также вас может заинтересовать статья «Про процессный подход», где вы также можете подробно прочитать о том, почему важны процессы и как с ними работать.

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

Подробнее о BPMN вы также можете почитать в моих публикациях.

• Сравнение нотаций IDEF3, IDEF0, BPMN и DFD

• Как описать бизнес-процесс в формате нотации BPMN и других.

Независимо от выбора инструмента, диаграмма должна отвечать на вопрос «Как мы хотим получить тот или иной результат».

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

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

Текстовое описание

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

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

Например, в графической модели мы указали «Создать заявку». В самой диаграмме этого достаточно. Но в текстовом описании мы указываем, что необходимо для создания заявки. Это может быть перечень полей (Клиент, Сумма заявки, Комментарий и пр.).

Аналогично при создании Сделки на основе заявки, в тексте описываются поля «Сумма сделки», «Перечень товаров», «Клиент», «Этап» и т.д.

Требования к текстовому описанию:

• Текстовое описание должно полностью описывать тот процесс, который есть в графическом описании.

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

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

План

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

Например, у нас в процессе должен создаваться звонок и подключаться автоматически запись разговора. Значит, нам нужно:

• Подключить IP-телефонию, если она еще не используется.

• Интегрировать телефонию с системой.

• Настроить запись звонков и выбрать для этих записей хранилище.

Еще один распространенный пример – на данный момент сайт заполняется вручную. Необходимо настроить автоматическую выгрузку на сайт. В плане мы так и ставим задачу: «Автоматическая выгрузка данных на сайт. Разработка скриптов переноса данных из учетной системы на сайт информации».

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

Я лично так понимаю:

• Программист – это тот человек, который будет писать программный код.

• Консультант – человек, который будет контролировать работу программиста.

• Старший консультант – это человек, который будет осуществлять общее руководство проектом.

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

Требования к плану:

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

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

Пример плана

Счет и/или калькуляция

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

Здесь также все просто. Берем задачу, пересчитываем ее на рабочие часы, умножаем на стоимость часа и получаем расчет стоимости задачи. Саму методику вы можете изучить подробно в статье «Как рассчитать стоимость внедрения программного продукта»

Как рассчитать стоимость внедрения программного продукта

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

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

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

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

Внедрение состоит из двух основных этапов:

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

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

Стоимость настройки программы

На этом этапе работают специалисты двух профилей:

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

Оплата труда каждого участника процесса может быть рассчитана классическим методом:

«ставка за 1 час работы» * «количество времени»

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

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

Почему консультант и программист – это разные люди?

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

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

Почему не бывает хороших консультантов-программистов?

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

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

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

Потому, я всем рекомендую:

• Специалистам – выбрать направление, которое вам ближе. И совершенствоваться в нем.
• Заказчикам – избегать сотрудничества с программистом-консультантом в одном лице. Кажущаяся дешевизна завершится не лучшим образом. 

Как правильно экономить

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

Экономить можно и нужно, но делать это надо разумным образом:

1. Выбирайте грамотного консультанта.
2. Проведите качественное предпроектное обследование.
3. На основе грамотного решения нанимайте нужных специалистов в нужный период времени.

Почему обучение стоит дороже чем консультация

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

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

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

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

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

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

При консультировании он получает:

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

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

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

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

При этом необходимо:

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

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

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

Как налоги влияют на стоимость

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

Возьмем самый простой вариант. Компания работает по УСН, она оплачивает:

• 6% налогов плюс ещё 1% в случае превышения суммы в 300 тысяч рублей. 
• Дополнительно при оказании услуги в пользу государства и в качестве банковских услуг взимаются суммы за кассовое обслуживание, обналичивание или перевод средств. Эти сборы в общей сложности могут достигать 1,5% и более стоимости услуги. 

Таким образом, при сотрудничестве с организацией, работающей на упрощенной схеме налогообложения, к базовой стоимости услуги добавляются минимум 8,5%.

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

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

В любом случае важно понимать: все налоговые отчисления с прибыли всегда ложатся на покупателя. Так работает любой продавец товаров или услуг. И от системы налогообложения напрямую зависит сумма этой «налоговой» наценки.

3 времени: оплачиваемое, неоплачиваемое, календарное

В рамках любого проекта оперируют тремя видами времени:

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

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

1. Предоплаченное - заранее уплачивается фиксированный объем. В этом случае специалист заранее оценивает, сколько времени понадобится на выполнение работы. И, если ошибется в оценке, скорей всего, придется завершать работу, так сказать, “за своей счет”. При полной предоплате заказчику будет сложно пояснить, почему на ту или иную работу понадобилось больше времени.
2. Постоплаченное - затраты времени фиксируются по факту, после чего производится оплата, исходя из тарифа. Удобный вариант в случаях, когда нужны нетиповые доработки, которые сложно оценить заранее, либо для каких-то вспомогательных услуг. Например, индивидуальное обучение руководителя или ведущего специалиста. Количество часов будет таким, какой понадобится. Используется этот вариант обычно, когда, повторюсь, прогнозировать объем работы сложно, а фиксировать затраченное время - нет. Т.е. либо при личном присутствии, либо при работе за компьютером с использованием программ-таймеров и т.д.
3. Смешанное. В этом случае исполнитель берет предоплату за выполнение определенной работы, но, также заранее оговаривается некоторый объем дополнительного времени “на всякий случай”. Заказчику это удобно, так как с одной стороны, у него есть некоторый “запас” времени, запланированный заранее, с другой - такой подход позволяет снизить сумму предоплаты, ведь исполнитель не будет закладывать в предоплату все возможные нюансы. Исполнитель будет работать с пониманием, что в случае необходимости, у него есть запас времени, который также будет оплачен. В результате он может выставить более привлекательное для заказчика предложение по цене. Здесь важно только одно - заранее оговорить, как именно вы будете подтверждать необходимость использовать дополнительное время. Если вы не фиксируете все возможные случаи заранее, возможны конфликты.

Как снизить стоимость за счет календарного срока

Если вы хотите, чтобы стоимость проекта была ниже, необходимо делать его быстро. С другой стороны, быстро – не значит «вчера». Времени должно быть столько, сколько объективно нужно специалистам. Но без дополнительных проволочек.

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

Соотношение: цена-качество-срок

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

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

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

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

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

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

Как рассчитывается стоимость той или доработки в системе

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

Как производится расчет стоимости такой работы:

(«количество часов работы программиста» * «цена часа работы программиста» + «количество часов работы консультанта» * «цену часа работы консультанта) * «коэффициент неопределенности».

Последний параметр рассчитывается с учетом проекта, это может быть от 30 до 50% стоимости «чистой работы». Он необходим, чтобы в случае появления каких-то непредвиденных сложностей или неуказанных заказчиком заранее полей документов или типов данных, которые необходимо интегрировать, не приходилось заниматься перерасчетами стоимости. Практика показывает, что такие ситуации возникают практически всегда.

Например:

• Цена часа программиста – 2 500 руб.
• Доработка будет длиться 4 часа.
• Работа консультанта – 1,5-2 часа (она включает в себя переговоры с заказчиком, постановку технического задания программисту, контроль качества).
• Цена часа работы консультанта 4200 руб.

Получается:

• Работа программиста: 2500*4 = 10 000 руб.
• Работа консультанта: 4200 *2 = 8400 руб.

Доработка стоит 18400 руб.

Как снизить стоимость доработки

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

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

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

Как цена руководства влияет на проект

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

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

На самом деле, заказчик всегда оплачивает услуги руководителя проекта, и при внедрении программных продуктов, и при заказе услуг бригады по ремонту квартир. Просто в некоторых случаях эту сумму «прячут» в других тарифах.

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

Как снизить стоимость руководства

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

Почему некоторые проекты «не взлетают» дальше продажи

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

Малый и средний бизнес испытывает серьезные проблемы с поиском специалистов по внедрению, и нередко дорогостоящие программные решения остаются «в коробке на полке». 

Почему так происходит, давайте разберемся на примере программной системы 1С ERP.

Стоимость этого корпоративного продукта составляет 455 тыс. рублей. Из этой суммы 55% – наценка франчайзи, т.е. торгового партнера компании 1С. Цифра эта не относится к секретной, в разделе для партнеров 1С на официальном сайте компании можно увидеть, какие проценты от стоимости они готовы отдавать своим официальным представителям.

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

Немного про Agile

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

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

Сегодня нередко эту технологию предлагают использовать при внедрении программных систем для бизнеса. Как это выглядит:

1. Проект разбивается на небольшие этапы, каждый из которых выполняется после завершения предыдущего.
2. Оплата производится за каждый этап отдельно.

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

Минусов намного больше:

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

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

Проект это не проект, цельное. Agile это фрагментарность, и поэтому нельзя “вести проект по методологии Agile”, это взаимоисключающие понятия.

Заказчик тоже несет затраты

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

Персонал

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

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

Простои и убытки от неправильных действий

Переход на новое программное обеспечение, новые инструменты в работе всегда связаны с какими-то недочетами, т.е. с тем самым «человеческим фактором».

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

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

Как снизить расходы

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

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

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

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

Подведем итоги

Стоимость внедрения основана на объективных факторах:

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

Своим заказчикам я часто повторяю известное изречение: “Хороший руководитель смотрит не на то, сколько он потратил, а на то, сколько осталось до результата”.

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

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