Что
лучше - учить всех пользователей или
учить небольшую группу пионеров, с
тем, чтобы они далее распространили
полученные знания? Некоторые возможные
критерии
группировки:
-
по
полу,
-
по
принадлежности к одному подразделению
(так оно часто и бывает),
-
по
возрастным группам,
-
по
выявленным симпатиям (наиболее
предпочтительный) (между членами
или к преподавателю),
-
по
образованию,
-
по
восприимчивости,
-
по
IQ,
-
по
выполняемым в производственным
функциям,
-
по
роли в обработке информации,
-
по
отношению к информации (потребители,
формирователи, читатели, корректоры,...),
-
по
темпераменту (кто сказал, что надо
смешивать холериков, флегматиков,
сангвиников как 1:1:1?),
-
по
числу незнакомых или малознакомых
друг с другом людей,
-
по
сходной мотивации.
Поскольку
мы все же занимаемся информационными
технологиями, то вышеизложенные
принципы группировки могут отодвигаться
на второй план, и обучаемых часто
разделяют, не мудрствуя лукаво, на
три очевидных потока:
У
каждого потока, естественно, свой
курс.
Обучение
конечных пользователей работе с
системой производится одновременно
с внедрением ИТ, и должно проводиться
только на рабочих местах и на
настроенном модуле системы.
Отечественная специфика может
сказаться и на этом, теоретически
самом простом этапе. Вполне возможны
случаи не только пассивного ("не
понимаю", "не удобно", "нет
времени"), но и активного
сопротивления, включая сознательные
попытки вывести систему из строя,
ввод недостоверных и заведомо опасных
данных. Поэтому желательно проводить
данный этап с полностью настроенной
системой разделения доступа и
соблюдением всех мер и правил
информационной безопасности. Хотя
в большинстве случаев мы можем
наблюдать, что явные знания индивидуумов
увеличиваются в результате самообучения
(чтения литературы, методической
документации), однако создание
творческой атмосферы и внутренняя
мотивация благоприятствует созданию
индивидами инноваций (как явных -
изобретений, так и неявных - новых
методов работы).
Как
правило, обучение проводится силами
группы по внедрению, однако крайне
редко удается обойтись без услуг
внешних консультантов. К сожалению
отечественный рынок управленческого
консалтинга до сих пор только
формируется, и не всегда можно найти
специалистов для решения конкретных
частных вопросов, которые возникают
в течении работы с проектом.При
использовании же услуг консультантов,
не достаточно владеющих особенностями
деятельности машиностроительных
предприятий, следует иметь в виду,
что стандартный проект внедрения
ИС исходит из некоторых перечисленных
ниже предположений "по умолчанию",
вообще говоря, неверных в отечественной
практике.
-
руководство
предприятия имеет четкие стратегические
и тактические цели, в том числе в
области информатизации и
компьютеризации, в частности, любой
процесс начинается с постановки
целей и оценивается по достигнутым
результатам, времени их достижения
и затратам (при одновременной
разработке адекватного письменного
описания поставленных целей);
-
приоритеты
находятся в области поддержки
информатизации планирующих и
управляющих технологий, а не отчетных
(во всех смыслах) процедур. Дело в
том, что многие, если не все, отчеты
могут получаться и более простыми,
в том числе и ручными, методами и,
как правило, очень сложно объяснить
руководству, почем для их получения
нужен дорогостоящий продукт. Для
систем планирования ручная поддержка
существенно более трудоемка;
-
руководство
и специалисты заказчика умеют
применять или, по крайней мере, имеют
представление о стандартных
технологиях управления деятельностью,
таких как, SIC, MRP, Supply Chain, TQM и тому
подобных, и не требуется специальное
обучение в случаях использования
их элементов в проекте. Именно по
этой причине предварительное
обучение, причем на уровне консультантов
по внедрению, в России является
обязательным требованием успешного
проекта;
-
работает
иерархическая структура управления
- то есть распоряжения руководства
безусловно обязательны для
исполнителей;
-
участники
проекта со стороны предприятия
безусловно положительно относятся
к повышению квалификации (приобретению
знаний, умений) которая будет
происходить в связи с выполнением
проекта. Как это ни странно, это
часто оказывается не верно, особенно
на периферии, особенно если даже
основная зарплата выплачивается с
задержкой. Это связано часто с тем,
что такое обучение требует
дополнительных затрат времени и
сил, как правило сверх и так
ненормированного рабочего дня, при
отсутствии реальных материальных
и карьерных стимулов. Если присутствует
дополнительное материальное
стимулирование процесса внедрения,
то часто таких казусов удается
избежать;
-
"личный"
фактор. В большинстве случаев у нас
отношения в коллективе основаны на
личных (неформальных) отношениях,
поэтому изменение положения человека
в худшую сторону всегда воспринимается
как личная трагедия. В связи с тем,
что в команду внедрения привлекаются,
как правило, специалисты, имеющие
статус "перспективных", то их
отстранение от работ приводит часто
к неадекватной реакции, вплоть до
действий попадающих под юридическое
определения саботаж и вредительство.
Практически всегда имеют место
попытки сформировать резко негативное
отношение к проекту и его участникам.
Для
того чтобы определить необходимую
степень участия сторонних специалистов
или потребность в собственных
ресурсах, нужно четко определить
цели и задачи проекта и детально
выявить существующие связи проекта.
Цели и задачи проекта определяют
уровень опыта и знаний специалистов,
которых необходимо привлечь к
выполнению проекта.
Говоря
об обучении системных администраторов,
можно констатировать, что UNIX
(в силу его распространенности в
качестве платформы для корпоративных
решений) на достаточно высоком уровне
у нас в стране знают единицы. Для
многих, например, является достаточно
серьезной такая задача - переписать
информацию с DDS-ленты одного компьютера
на DDS-ленту другого компьютера, не
пользуясь при этом жестким диском.
Ничего не поделаешь: UNIX - это как
автомобиль для "Формулы-1" - надо
постоянно обслуживать. Сложно
организованные системы требуют
настройки и постоянного слежения
за своими параметрами. Неграмотный
системный администратор может
привести любую систему к краху,
например, не читая и не чистя вовремя
лог-файлы.
Работа
с программистами - это три позиции:
-
• обучение
системе (инструменту) программирования,
-
• обучение
предметной области для программирования,
-
• обучение
управлению разработкой.
Большинство
систем имеют свои инструментальные
системы для программирования (ABAP/4,
разные диалекты 4GL). Но есть и целиком
написанные, например, на ORACLE,
C,
и поэтому надо опираться на этот
инструмент. В принципе здесь все
понятно - если человек успешно
пересылает байты, то его можно учить
и дальше.
Обучение
программистов предметной области
обычно происходит достаточно
болезненно. Не многие программисты
до сих пор хватаются за пистолет от
слова "проводка", но среди нет
в массе своей желания разбираться
в задачах. Они требуют хорошо
поставленную задачу на программирование
(ТЗ) и звереют, когда ее не получают.
Здесь объективно есть проблема -
программисты не хотят двигаться
навстречу предметникам, а у предметников
часто не хватает культуры формализации
своих задач.
Обучение
управлению разработкой (или доработкой)
ПО - тоже отдельная тема. Люди для
этого у нас появляются, но и их разумно
немного подучить. Разработка - это
ведь нормальный проект, имеющий
ресурсные и временные ограничения.
И надо уметь его представлять именно
с этой позиции. Потом надо брать
систему ведения проектов (что-нибудь
типа Primavera PP) и разрабатывать проект.
|