Как решить проблему с передачей опыта от исполнителя клиенту
На мой взгляд, возможность развивать знания и опыт своих сотрудников при внедрении ИТ-решений определяют не столько процедуры, сколько среда.
«Заимствование знаний у консультантов является одним из ключевых факторов успеха проектов внедрения ИТ-систем. Проект завершен, система внедрена и недальновидный заказчик оказывается перед непростым выбором: остаться наедине с ней, платить за ее поддержку консультантам или принимать в штат дорогостоящих экспертов. Какие действия предпринять, чтобы знания не ушли из компании вместе с внедренцами?»
Это аннотация к статье
Николая Смирнова «Обретение
компетенций».
Из названия я ожидал увидеть разбор существующих методов и выделение из них
наиболее эффективных. К сожалению, в ней приведено только несколько примеров
того, кто и как решил свою проблему. А как же насчет самих механизмов передачи
опыта и организации развития опыта сотрудников? Возможно, цель статьи несколько
иная, но именно эти вопросы и хочется рассмотреть.
На мой взгляд, возможность развивать знания и опыт своих сотрудников при
внедрении ИТ-решений определяют не столько процедуры, сколько среда.
Например, есть «Компания с невероятными знаниями и умениями». Она внедряет свой
продукт в другую организацию. В ходе проекта передана необходимая
технологическая документация, обучены специалисты заказчика. По окончанию
проекта компания уходит заниматься другими проектами. Клиент остается в
замкнутом информационном пространстве: развивает систему сам и справляется со
своими задачами методом проб и ошибок.
Но может быть и по-другому, когда компания не оставляет клиента с задачами и
вопросами один на один, а пытается обеспечить среду, в которой опыт можно
черпать ровно настолько, насколько он требуется в текущий момент. Например,
создает профессиональное сообщество, постоянно наращивает и развивает его.
Здесь администраторы, разработчики, внедренцы делятся опытом и помогают
советами друг другу. Очевидно, что во втором случае проблема с передачей опыта
решена лучше.
Другая проблема – скорость передачи опыта. Обычно много знаний сразу требуется
перед тем, как начать что-то делать. Особенно, если ты этим раньше не
занимался. Для таких случаев компания организовывает специальные семинары и
тренинги, создает форумы, конкурсы, практические вебинары и различные
мероприятия. В этом случае остается просто выбрать подходящий для себя вариант.
Итого, на мой взгляд, для того, чтобы обеспечить процесс и возможность передачи
опыта от исполнителя клиенту требуется два ключевых условия:
1. Наличие профессионального сообщества и специализированного ресурса (форума
или другого);
2. Наличие возможности обучаться на специализированных курсах и тренингах для
получения нужных знаний.
Похожие статьи
Комментарии 5
Дельное сообщение. На мой взгляд, важны и формальные процедуры и курсы и среда для общения. Вообще без процессов, заказчика оставлять нельзя. Необходимо, как минимум, оставить процесс управления инцидентами и управления изменениями. Лучше с готовыми шаблонами (checklists), позволяющими типизировать обращения пользователей и настраивать/чинить решение. По инцидентам обычно так все и делают. Заказчик берет на себя второй уровень поддержки, а поставщик третий (инциденты, которые нельзя решить без доработок ПО превращаются в дефекты на разработчика). С управлением изменениями ситуация хуже. Я могу по пальцам пересчитать случаи когда проект внедрения ИТ решения оставлял после себя внятные процедуры внесения заказчиком изменений в систему (настройка новых типов документов, изменения workflow и т.п.).
И в том и в другом процессе бывают исключительные ситуации, которые не предусмотрены в процессах. Вот здесь и появляется необходимость посоветоваться с комьюнити. Недавно Роб Ингланд рассказывал об этом на 24-х часовом марафоне TFT12 – Tomorrow’s IT Service Future Today. Подробнее у меня в блоге http://wp.me/pRljZ-oO
Профессиональные сообщества, например, форумы позволят обмениваться информацией и передавать знания узкому кругу людей. Это не будет влиять в целом на компанию, на передачу экспертных знаний о том как жить по-новому всей организации.
Собственно я бы выделил другие факторы передачи опыта:
1. Просто обучения продукту недостаточно. Нужно научить сотрудников работе в новой реальности, довести до них те "полезности", которые они могут извлекать после внедрения новой системы. По сути это консалтинговый проект, например, типа тайм-менеджмента Архангельского когда в центре не продукт, а то как людям лучше и эффективнее работать, продукт просто подкрепляет эту тему как инструмент.
2. Заказчик должен захотеть получать чей-то опыт, захотеть научиться чему-то новому и полезному. Таких очень мало, большинство себя считают гуру и нередко поучают подрядчика. Здесь, конечно, важным фактором является репутация и профессионализм подрядчика именно в области методологии. А с этим на рынке плохо, к сожалению, в большинстве своем технари внедряющие платформы.
3. Заказчику НЕ НУЖНО перенимать технический опыт, ему не нужно становится экспертом в выбранной платформе. Любая компания должна быть экспертом в своей области. К сожалению часто бывает наоборот - методологические и экспертные темы заказчик не перенимает, но технически пытается развиваться, посылает сотрудников на курсы, осваивает тонкости платформы...
Я согласна с Александром. Нужно помогать заказчику разбираться с методологией и помогать выстраивать работу с учетом внедренной системы.
Естественно, внедрять систему должны не технари, а методологи с поддержкой технических специалистов.
И было бы замечательно, если бы разработчик предлагал и методические услуги после внедрения, либо взаимодействовал с какой-либо консалтинговой компанией.
Елена и Александр, я согласен с тем, что людей надо учить не столько информационным системам, сколько методам работы. Но разве кто-нибудь умеет это делать? Где готовят таких "методологов" и какие техники они используют?
В моем опыте наиболее успешный кейс такого обучения выглядел следующим образом: Руководитель в грубой форме приказал мне быстро завершить проект выпуска и распространения скретч-карт оплаты. Система был практически настроена. Я притащил в комнату шесть рабочих мест и пригласил руководителей основных функций (отделов и служб), задействованных в процессе. Из 6 руководителей 4 пришли сами, основные делегировали своих операционных заместителей. Расписал несколько use-case-ов в стиле Алистера Коберна о том, как мы заказываем и получаем эти карты оплаты; обрабатываем заявки дилеров, принимаем от них авансовые платежи или отгружаем карты в долг, взаиморасчитываемся, ну и т.д. Мы на день закрылись в комнате и осуществляли все эти сценарии. По ходу что-то исправили, о чем-то договорились, зафиксировав это на салфетке. В итоге, я получил зеленый свет на запуск и функции стали работать по-новому.
Было это довольно давно и в нашей организации была совершенно другая корпоративная культура. Жалею, что в тот момент не «подсадил» эти бизнес-функции на общий социальный ресурс (дилеры, к тому моменту такой ресурс уже использовали).
Но я айтишник, я эти техники добываю методом проб и ошибок. А как правильно?
Максим, ваш пример очень хорош, но это я бы сказала эвристическое решение. На поток как такое поставить, пока не знаю. Мне кажется эта тема близка к управлению знаниями. если говорить об успешных кейсах, то примеры есть тут http://ecm-journal.ru/docs/Socialnye-reshenija-po-upravleniju-znanijami.aspx Хотя, что интересно, опять же речь идет о знаниях в сторону техническую...
Как обучиться культуре? Тут часто работает "погружением в среду", как при обучение английскому. Может быть уже надо делать как в советские времена при дежеке опытом "обучение на рабочем месте", когда обучаемый сидит рядом и смотрит как работают в «Компании с невероятными знаниями и умениями».