Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

Как решить проблему с передачей опыта от исполнителя клиенту

  5 комментариев Добавить в закладки

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

Это аннотация к статье Николая Смирнова «Обретение компетенций».

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

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

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

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

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

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

Ещё материалы автора
Похожие записи
Комментарии (5)
Максим Смирнов 18 декабря 2012 г. 20:47  

 

Дельное сообщение. На мой взгляд, важны и формальные процедуры и курсы и среда для общения. Вообще без процессов, заказчика оставлять нельзя. Необходимо, как минимум, оставить процесс управления инцидентами и управления изменениями. Лучше с готовыми шаблонами (checklists), позволяющими типизировать обращения пользователей и настраивать/чинить решение. По инцидентам обычно так все и делают. Заказчик берет на себя второй уровень поддержки, а поставщик третий (инциденты, которые нельзя решить без доработок ПО превращаются в дефекты на разработчика). С управлением изменениями ситуация хуже. Я могу по пальцам пересчитать случаи когда проект внедрения ИТ решения оставлял после себя внятные процедуры внесения заказчиком изменений в систему (настройка новых типов документов, изменения workflow и т.п.).

И в том и в другом процессе бывают исключительные ситуации, которые не предусмотрены в процессах. Вот здесь и появляется необходимость посоветоваться с комьюнити. Недавно Роб Ингланд рассказывал об этом на 24-х часовом марафоне TFT12 – Tomorrow’s IT Service Future Today. Подробнее у меня в блоге http://wp.me/pRljZ-oO

Александр Сидоренков 20 декабря 2012 г. 13:51  

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

Собственно я бы выделил другие факторы передачи опыта:

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

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

3. Заказчику НЕ НУЖНО перенимать технический опыт, ему не нужно становится экспертом в выбранной платформе. Любая компания должна быть экспертом в своей области. К сожалению часто бывает наоборот - методологические и экспертные темы заказчик не перенимает, но технически пытается развиваться, посылает сотрудников на курсы, осваивает тонкости платформы...

Елена Дмитриева 21 декабря 2012 г. 10:39  

 

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

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

Максим Смирнов 22 декабря 2012 г. 11:05  

 

Елена и Александр, я согласен с тем, что людей надо учить не столько информационным системам, сколько методам работы. Но разве кто-нибудь умеет это делать? Где готовят таких "методологов" и какие техники они используют?

В моем опыте наиболее успешный кейс такого обучения выглядел следующим образом: Руководитель в грубой форме приказал мне быстро завершить проект выпуска и распространения скретч-карт оплаты. Система был практически настроена. Я притащил в комнату шесть рабочих мест и пригласил руководителей основных функций (отделов и служб), задействованных в процессе. Из 6 руководителей 4 пришли сами, основные делегировали своих операционных заместителей. Расписал несколько use-case-ов в стиле Алистера Коберна о том, как мы заказываем и получаем эти карты оплаты; обрабатываем заявки дилеров, принимаем от них авансовые платежи или отгружаем карты в долг, взаиморасчитываемся, ну и т.д. Мы на день закрылись в комнате и осуществляли все эти сценарии. По ходу что-то исправили, о чем-то договорились, зафиксировав это на салфетке. В итоге, я получил зеленый свет на запуск и функции стали работать по-новому.

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

Но я айтишник, я эти техники добываю методом проб и ошибок. А как правильно?

Елена Питомцева 26 декабря 2012 г. 16:42  

Максим, ваш пример очень хорош, но это я бы сказала эвристическое решение. На поток как такое поставить, пока не знаю. Мне кажется эта тема близка к управлению знаниями. если говорить об успешных кейсах, то примеры есть тут http://ecm-journal.ru/docs/Socialnye-reshenija-po-upravleniju-znanijami.aspx Хотя, что интересно, опять же речь идет о знаниях в сторону техническую...

Как обучиться культуре? Тут часто работает "погружением в среду", как при обучение английскому.  Может быть уже надо делать как в советские времена при дежеке опытом "обучение на рабочем месте", когда обучаемый сидит рядом и смотрит как работают в «Компании с невероятными знаниями и умениями».

Сейчас обсуждают
Больше комментариев