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

Гёте

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

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

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

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

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

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

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

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

Бе́та-тести́рование (англ. 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 раза в месяц) отправляю отчет о проделанной работе и выставляю счет.

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

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

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

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

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

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

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

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

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

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

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

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

С уважением Кинзябулатов Рамиль.

Автор:

Источник