Обещали видеозапись, может быть появится информация на странице мероприятия itsmforum.ru/events/2011_10_19. Ну или напрямую написать Елене Карабановой.

Удачи!

Часть персонала, скажем так, нормально относится к построению и запуску процессов. Часть (довольно большая) относится нейтрально. Конечно же, есть и негатив.

«И это ох как непросто...» — но ведь получается?) Тут по-моему, прежде всего должна быть заинтересованность в самих процессах управления, и если она есть, то действительно, контент и системы вторичны.

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

Нечто вроде IBM Tivoli Unified Process, только для той системы управления, которая выстраивается у клиента.

Из моей реальной MS-практики, он веселее идёт, когда акцент не на support-составляющую (inc, sd, prb), а скорее на operations (эксплуатация; новые учётки, миграция, бэкапы, анализ производительности — из этой серии). Любой нормальный админ заинтересован в том, что бы рутинной работы выполнять как можно меньше. Хорошо, на тебе консультанта по operations, выявляйте основные роли, зоны ответственности. На тебе инженера по технологии, садитесь и ваяйте перечень основных тасков, которые выполнять по этой системе надо. Грузите это всё в систему (надстройка над sharepoint), шедульте, назначайте на роли. Если речь идёт о технологиях Майкрософт (эксчендж, сиквел, ад, и т.д.) — то на тебе сразу готовый контент-пак с перечнем всех возможных тасков и готовыми инструкциями к каждому из них, всё кастомизируется. Для сторонних систем конечно придётся писать самому.

В идеале на выходе имеем перечень адекватных операционных ролей, каждая роль понимает что и когда ей делать, на каждую операцию есть пошаговая инструкция. Приходит новый человек или снимаем задачу с большого админа и вешаем её на маленького — на тебе роль, иди в систему, смотри свои задачи, читай как делать. Есть отчётность, отслеживаем выполнение задач, смотрим трудозатраты на каждую, можем корректировать. Можно смотреть ещё и загрузку по каждой из роли, махать перед руководством аргументами относительно новых позиций в отделе.

Вот так оно понятнее жертвам. А реально работающего красивого и чистого Knowledge Managementa нет, не видел. Но он, конечно, существует

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

*

...Хотя сам я всё же считаю, что knowledge management — скорее функция, чем процесс.

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

Очень понятно, что заниматься этим надо.

Вроде понятно, что формальный процесс городить довольно глупо.

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

Но целостной картины у меня в голове пока нет.

Вот прямо сейчас делаем проект у одного из клиентов по формированию собственной и внутренней базы знаний по системе управления ИТ. Стало ещё очевиднее что контент, и тем более система автоматизации этой базы знаний — дела второго приоритета. Главное — заинтересовать потенциальных жертв этой базы знаний, чтобы они получили ежедневно используемый инструмент. И это ох как непросто...