Формирование групп

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

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

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

• пользователи,
• системные администраторы,
• программисты.

У каждого потока, естественно, свой курс.

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

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

• руководство предприятия имеет четкие стратегические и тактические цели, в том числе в области информатизации и компьютеризации, в частности, любой процесс начинается с постановки целей и оценивается по достигнутым результатам, времени их достижения и затратам (при одновременной разработке адекватного письменного описания поставленных целей);
• приоритеты находятся в области поддержки информатизации планирующих и управляющих технологий, а не отчетных (во всех смыслах) процедур. Дело в том, что многие, если не все, отчеты могут получаться и более простыми, в том числе и ручными, методами и, как правило, очень сложно объяснить руководству, почем для их получения нужен дорогостоящий продукт. Для систем планирования ручная поддержка существенно более трудоемка;
• руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления деятельностью, таких как, SIC, MRP, Supply Chain, TQM и тому подобных, и не требуется специальное обучение в случаях использования их элементов в проекте. Именно по этой причине предварительное обучение, причем на уровне консультантов по внедрению, в России является обязательным требованием успешного проекта;
• работает иерархическая структура управления - то есть распоряжения руководства безусловно обязательны для исполнителей;
• участники проекта со стороны предприятия безусловно положительно относятся к повышению квалификации (приобретению знаний, умений) которая будет происходить в связи с выполнением проекта. Как это ни странно, это часто оказывается не верно, особенно на периферии, особенно если даже основная зарплата выплачивается с задержкой. Это связано часто с тем, что такое обучение требует дополнительных затрат времени и сил, как правило сверх и так ненормированного рабочего дня, при отсутствии реальных материальных и карьерных стимулов. Если присутствует дополнительное материальное стимулирование процесса внедрения, то часто таких казусов удается избежать;
• "личный" фактор. В большинстве случаев у нас отношения в коллективе основаны на личных (неформальных) отношениях, поэтому изменение положения человека в худшую сторону всегда воспринимается как личная трагедия. В связи с тем, что в команду внедрения привлекаются, как правило, специалисты, имеющие статус "перспективных", то их отстранение от работ приводит часто к неадекватной реакции, вплоть до действий попадающих под юридическое определения саботаж и вредительство. Практически всегда имеют место попытки сформировать резко негативное отношение к проекту и его участникам.

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

Говоря об обучении системных администраторов, можно констатировать, что UNIX (в силу его распространенности в качестве платформы для корпоративных решений) на достаточно высоком уровне у нас в стране знают единицы. Для многих, например, является достаточно серьезной такая задача - переписать информацию с DDS-ленты одного компьютера на DDS-ленту другого компьютера, не пользуясь при этом жестким диском. Ничего не поделаешь: UNIX - это как автомобиль для "Формулы-1" - надо постоянно обслуживать. Сложно организованные системы требуют настройки и постоянного слежения за своими параметрами. Неграмотный системный администратор может привести любую систему к краху, например, не читая и не чистя вовремя лог-файлы.

Работа с программистами - это три позиции:

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

Большинство систем имеют свои инструментальные системы для программирования (ABAP/4, разные диалекты 4GL). Но есть и целиком написанные, например, на ORACLE, C, и поэтому надо опираться на этот инструмент. В принципе здесь все понятно - если человек успешно пересылает байты, то его можно учить и дальше.

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

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