Реализация Программного Продукта. Особенности Работы Бизнес-Консультанта. Часть Iii. Финал

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

Недостаточно просто желать, это надо сделать.

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

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


Реализация программного продукта.
</p><p>
 Особенности работы бизнес-консультанта.
</p><p>
 Часть III. Финал

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

Есть много причин для этого.

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

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

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

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

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

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

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

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



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

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

Пришло время тщательно проверить работу программы, т.е.

тестовую эксплуатацию.

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

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

Этот этап можно назвать бета-тестированием, т.е.

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

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

массам, потребителю.

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

Википедия

По сути, бета-тестирование — это проверка работы уже готового программного продукта.

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

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

  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. Тестирование с непосредственными участниками процесса проходит в режиме, максимально приближенном к реальной работе.

    Люди выполняют свои обязанности в новой программной среде.

    Они проверяют, насколько удобно и корректно работает система.

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

Пусть люди работают в двух системах параллельно.

Им не нужно дублировать все.

Но по возможности следует работать в обеих системах.

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

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

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

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

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

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



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

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

Что будет дальше:

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

  • Все необходимые интеграции присутствуют и работают хорошо.

  • Имеется вся необходимая для работы документация.

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

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

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

Важно понимать, что запуск — это еще не закрытый проект. Объясните это и клиенту.

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

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

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

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

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

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

Например, когда я запускал программный продукт в пекарне, я спал по 3-4 часа в сутки в течение 3 дней.

Я был в компании почти все время.

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

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

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

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

Далее любая работа будет оплачиваться отдельно.

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

и убедитесь, что все работает как надо.

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

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

И они все равно обратятся к вам за улучшениями.

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

Как объяснить это клиенту? Вы не сможете долго держать программиста на этом проекте после окончания работы.

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

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

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

Не стесняйтесь откровенно объяснить свой подход к работе.

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

Поэтому ваши аргументы будут им близки и понятны.



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

Эскорт

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

Более того, я лично почти всегда обеспечиваю сопровождение удаленно.

Как это произошло:

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

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

    После чего мне высылается этот пакет информации.

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

    Для этого я использую систему Redmine. Конечно, это не обязательно, просто лично мне удобно.

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

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

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

Поэтому сопровождение не приносит особой прибыли.

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

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

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

сиденье".

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

И не беспокойтесь о том, что вы упустите какую-либо прибыль.

Вы получите еще больше благодаря этим факторам:

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

  • Благодарный клиент порекомендует вас своим друзьям.

    А такая реклама стоит немало.

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

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

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

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

Поэтому по окончании проекта время от времени возникают недопонимания и разногласия с клиентом.

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

Для вас проект завершен, а для клиента все только начинается.

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

эффективность.

И ты уже уходишь.

Конечно, такие разногласия возникают не всегда.

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

Но, тем не менее, такое случается в жизни.

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

Да, вам уже заплатили.

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

Но не забывайте, что этот человек вам заплатил.

И он заплатит, возможно, не один раз.

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

, над которым мы работали еще эффективнее.

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

Напомню, что эта ниша в нашей стране до сих пор незаполнена.

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



Реализация программного продукта.
</p><p>
 Особенности работы бизнес-консультанта.
</p><p>
 Часть III. Финал

Теги: #Управление проектами #фриланс #бизнес-консультант #фриланс
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.