Управление проектами, менеджеры проектов
itSMF объявил о публикации интересного документа, раскрывающего один из используемых в реальной жизни подходов к построению и предоставлению отчётности об уровне сервиса. Помимо весьма достойного содержания, этот документ интересен ещё и тем, что является победителем конкурса, проведённого itSMF UK в прошлом году. Автор документа – Ян Макдональд (Ian MacDonald) из компании Co-Operative Financial Services. Скачать и читать.
В конце июля, в воскресенье 25-го числа, из Москвы в Санкт-Петербург отправились два наших бойца – Роман и Лариса. К одному из заказчиков на предмет чтения учебного курса, с возможным последующим консалтингом. В тот же вечер, из той же Москвы в тот же Питер отправился ещё один боец – Дмитрий. Проводить семинары детального проектирования у другого клиента. Ранним утром понедельника, 26-го июля, в 6-45 из Москвы в Петербург на шайтан-арбе "Сапсан" поехал и я. К третьему заказчику на семинары концептуального проектирования. Размышлял над этой трудовой миграцией. Это совпадение, случайность? Или в славном городе на Неве оживает ITSM? Если так, но…
На прошлой неделе был в гостях в одной очень большой компании, известной своими работами на ниве внедрения ITSM. Они уже запустили несколько оперативных процессов, спроектировали и начали исполнять ещё целый ряд процессов. На столе "самого главного человека по ITSM" в этой организации заметил нашу книжку, "Введение в реальный ITSM". Моё внимание привлекло множество маленьких закладок, прилепленных к разным страницам книжки. А при ближайшем рассмотрении выяснилось, что целые абзацы текста в некоторых местах книги выделены ярким жёлтым маркером. Вот как нужно работать с литературой. С одной стороны книжка, конечно же, сатира и юмор, лёгкое чтение. С другой – полезно иметь её…
Мы стали активно интересоваться BPMN около года назад и даже написали об этом статью (https://cleverics.ru/subject-field/hot-issues/bpmn). Статья содержала пример диаграммы BPMN с несколькими ошибками 🙂 Время шло, проекты делались, мысли копились. В пятницу отправил заказчику пакет процессной документации, в том числе несколько регламентов процессов. Все документирование процессов выполнено в BPMN. Решил зафиксировать текущие мысли. С одной стороны, BPMN это действительно удобно. Диаграммы получаются короче и точнее, чем, например, в CFD (за счет использования специальных графических элементов). Они не то чтобы содержат больше информации, они позволяют представить ее более наглядно, объяснить логику исполнения процесса, в том числе событий, взаимодействий нескольких процессов, параллельных…
Не могу не поделиться. Вчера, по долгу службы, получил на рецензию регламенты процессов управления инцидентами и проблемами, которые одна уважаемая компания-консультант разработала для своего заказчика. Никаких имен, никаких фактов и цитат (хотя, реально жаль, что не могу поделиться этим шедевром). Читал я читал, думал-думал и понял, что хочу сформулировать манифест, отражающий наше (команды Cleverics и мое лично) отношение к процессной документации: Не превращать регламент процесса в книгу о процессе, в которой пространно излагается, что "бывает такая ситуация, а бывает другая ситуация, а правила для определения сроков определить невозможно, а сопоставление бывает выполнить очень сложно, но надо стараться и полагаться на…
Принципы ITSM применимы к организациям любого масштаба. Тем не менее, применяемая процессная модель, распределение ролей, механизмы управления, требования к системам автоматизации зависят от масштаба организации. Например, рекомендации ITIL v3 учитывают особенности крупных и очень крупных организаций. Существуют адаптированные подходы, адресованные малым организациям. И всё же адаптация «книжной» модели ITSM под свой масштаб деятельности – задача руководителя ИТ-службы. Можно сформулировать основные правила такой адаптации для процессной модели, ролевой структуры, автоматизации деятельности, руководства и контроля. Подробнее на сайте Cleverics…
Вчера на конференции ОСП с громким названием ITSM-2010 сделал короткий доклад про совмещение процессного и функционального управления. Сам доклад разместили на сайте компании (и видео, и презентацию), а вот обсуждение можно сделать здесь. Как я рассказал в самом начале доклада, тема появилась из дискуссии с одним из заказчиков (весьма известный в ITSM-кругах банк 🙂 ), и, пока обсуждали, я, наконец-то, в ней разобрался. То, что раньше казалось сложным, разложилось по полочкам и стало довольно стройной картиной. Картина получила "боевое крещение" ещё в нескольких дискуссиях, и теперь я готов рассказать любому как же совместить несовместимое. Более того, в обсуждении с Димой…
Интересно, строители яхт тоже с грустью отдают свое творение новым хозяевам? Сколько процессов не запускал, всегда очень хочется через некоторое время вернуться и посмотреть, как оно там работает без меня? Ведь, как ни проектируй, как не автоматизируй, а все равно б-о-о-о-льшая часть успеха процесса будет зависеть от менеджера, который будет этой яхтой этим процессом управлять. Вот и задумываюсь, что можно сделать для того чтобы менеджер лучше справился с этой задачей. Конечно, сами собой разумеются: раннее вовлечение менеджера в проектирование процесса; выполнение менеджером сначала под контролем, а затем и самостоятельно, задач, направленных на успешный запуск процесса; формирование отчетов и их анализ, разработка мер совершенствования процесса; и…
В последнее время всё чаще встречаю слова "типовые процессы", "типовое решение", "типовое внедрение" и так далее. Разумеется, смысл слова "типовой" зависит от контекста и автора высказывания. Вот и получается, что говорят все одними и теми же словами, но про разные вещи. Читатель / собеседник в такой ситуации время от времени чуствует себя на месте Гедевана Алексидзе на планете Плюк: "Извините, а гравицапа это что?". Вот что я думаю обо всех этих "типовых" прелестях (приглашаю к дискуссии). Объясняю себе это на примере компании N, которой надо организовать у себя процесс управления … ну скажем изменениями (т.е. надо сделать так, чтобы сотрудники…
Каждый раз, сталкиваясь с задачей поиска консультанта в команду, я снова и снова думаю "кто все эти люди?". Вот кто такой консультант и где их продают? Мой личный профессиональный опыт говорит, что хороший консультант в области управления (это чтобы не путали с продавцами-консультантами) – это прежде всего не "широкообразованный эрудит в твидовом пиджаке и с трубкой в зубах", то есть не тот, кто знает, а тот – кто умеет и делает. То есть трудяга, потому как что бы помочь организации в решении управленческих проблем знаний мало. Знания, они, скорее всего, есть и в головах руководителей этой компании. А придётся хорошо…
Этот список бесконечен: ITIL, Six Sigma, Lean, TQM, Agile, Scrum, XP, APM, PMBOK, система сбалансированных показателей, управление портфелями…. Как кто-то умудряется ориентироваться во всём этом, получая пользу? Похоже, что почти никто не ориентируется и не получает.. Читать полный текст на DailyExchange.