Facebook Graph API

Я довольно давно не затрагивал тему adaptive case management. Не затрагивал, не потому что она мне стала не интересной. Просто последние несколько месяцев у меня очень много работы, связанной с практической реализацией ИТ поддержки такого рода процессов. В первую очередь, речь идет о процессах решения телеком инцидентов. Это тысячи тикетов ежедневно, необходимость оперативного доступа к данным о клиентах, договорах, адресах подключений, данным по сетевому оборудованию и предоставляемым сервисам. Все это по-разному работает для разных типов услуг, линий бизнеса, в разных информационных системах. Этот практический опыт подтверждает мои предыдущие наблюдения. Если бы мне сейчас пришлось писать Adaptive Case Management Manifesto я бы начал с того, что гибкость бизнес-процессов достигается разделением приложений для совместной работы и приложений управления данными.

Программная инженерия. Управление рисками

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

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

Небольшое отступление. То, что план проекта и расписание проекта – это не одно и то же, знают многие. Не многие помнят, что английское слово plan может являться не только существительным, но и глаголом. Хороший проектный менеджер считает, что план – это именно глагол, а не существительное.

Взглянув на управление рисками под таким углом зрения, мы тут же придем к выводу, что главное в управлении рисками – это качество планирования. Довольно бессмысленно, не составив план проекта, сидеть и придумывать риски и оценивать их вероятность. Но как только мы берем план, начинаем смотреть на обозначенные в нем цели, так сразу же обретаем способность оценивать их вероятность.

Другой вопрос в том, что практика планирования в управлении проектами подразумевает наличие единственного верного пути, приводящего нас к цели. Я ни разу не видел диаграмму Ганта, имеющую ветвления, условные переходы, альтернативные последовательности работ. Не знаю, почему так сложилось, но в проектном плане, в отличии, например, от модели бизнес-процесса, принято рисовать только один вариант действий. Это вам не use cases в стиле Алистера Коберна, описывающий основной сценарий, исключения и последовательности действий для обработки исключений. Ничего подобного в проектном менеджменте нет. Отчасти из-за этого и возникает необходимость в формулировании рисков (исключений, говоря языком use case-ов) и планировании последовательности действий, реализуемой при их возникновении.

Service Knowledge Management System

Недавно, в заметке О том как вендоры и аналитики победили ITIL я поспешил посетовать на технологическую отсталость баз данных управления конфигурациями CMDB. Безусловно, я был не прав. Нельзя по одной системе от конкретного вендора, используемой в нашей конкретной организации судить о всех системах подобного класса. Немного погуглив я наткнулcя на ряд интересных статей Hank Marquis-a:

• CMDB 3.0
• Future CMDB
• Configuration Management for the Rest of Us

Gartner: Projects Today, «Change Operations» Tomorrow

За пару дней до Нового года Андрей Коптелов поделился ссылкой на июльскую статью Владимира Иванова Доклад Gartner: Будьте готовы к будущему управления портфелями и программами проектов Я решил разобраться более подробно в том, что предрекает Gartner проектному менеджменту и кроме презентации Be Prepared For the Future of Program and Portfolio Management посмотрел их более ранние работы:

 

• Predicts 2011: PPM Goes From Managing Projects to Managing Value and Change
• Projects Today, ‘Change Operations’ Tomorrow

Не стану пересказывать статью Владимира Иванова. Позволю себе лишь несколько акцентов. Итак, аналитики предсказывают, что организации на треть сократят сроки и стоимость реализуемых проектов (Думаю, в наших условиях речь может идти о 50% и больше). Это приведет к серьезному давлению, как на проектные офисы, так и на средства их автоматизации. Системы управления проектами и портфелями проектов мне никогда не нравились, так что туда им и дорога. Впрочем, проектные офисы, в отличии от «боевых» проектных менеджеров, тоже приносили проблем больше чем результатов. Одним словом, предсказания аналитиков вполне созвучны и моим рассуждениям:

• Issue trackers: от проектов к кейсам (декабрь 2011)
• О вреде проектного управления (июнь 2010)

Резонный вопрос: как организовать Getting Things Done в условиях такого давления. Как справедливо замечают аналитики Gartner, проекты бывают разными. Значительная часть активностей, осуществляемых организациями, заключается в улучшениях уже существующих продуктов. Вести их в формате традиционных проектов, как-то совсем неразумно. Кстати, в ИТ уже давно существуют процессы управления проблемами и управления изменениями. Вопрос в том, насколько широко трактовать эти процессы. Например, замена устаревшей ИТ системы на новую, казалось бы, типичный пример ИТ проекта. В действительности, эта активность намного ближе к управлению проблемой (недостаточная масштабируемость или функциональность системы). Возможно, качественное решение проблем освободит нас от необходимости инициировать новый проект и внедрять новую ИТ систему. Это как раз то, о чем я собираюсь рассказывать в теме Интеграция новых приложений в корпоративный ИТ-ландшафт

Интеграция новых приложений в корпоративный ИТ-ландшафт

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

О том как вендоры и аналитики победили ITIL

Наверное, я один из немногих читателей книжки Роба Ингланда «Овладевая ITIL», которым эта книжка не нравится. Не нравится не потому, что я не согласен с приводимыми автором фактами и выводами. Наоборот, с большинством суждений о роли, месте и истинных мотивах популяризаторов ITSM я согласен. Мне не нравится подход IT sceptic-а. На протяжении всей книжки автор пишет о том, что построение ИТ-сервисов в соответствии с ITIL это очень дорого не всегда нужно, и потому предлагает действовать более прагматично. В одном направлении немножко поработать с процессами, в другом – немножко, вот всем и станет немного лучше.

Issue trackers: от проектов к кейсам

Вчера устроил небольшой флем на фейсбуке ссылкой на статью Почему Microsoft Project нельзя использовать для управления проектами Статья примечательна тем, что собрала множество комментариев как от людей, использующих трекеры задач, так и от «настоящих проектных менеджеров» трекеры не использующих. Их аргументы звучат примерно так: трекеры это только для ИТ-проектов, трекеры это для управления продуктами (вероятно, речь о PLM), трекеры предназначены для отслеживания локальных задач и не позволяют осуществлять планирование и т.д.

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

Учебный курс: ИТ архитектура предприятия

В преддверии Нового года принято строить планы и загадывать желания. Я собираюсь в начале 2012 года собрать имеющиеся у меня материалы в учебный курс по архитектуре информационных систем организации. Краткая презентация курса выглядит примерно так:

Я не собираюсь пересказывать учебник по UML или учить вас рисовать диаграммы в нотации Archimate. Мы не будем моделировать корпоративные java приложения и разбираться в тонкостях отображения объектно-ориентированных моделей в реляционной базе данных. Цель этого курса выделить базовые техники ИТ архитектуры, востребованные в современной организации. Разобраться что, когда и главное зачем должен делать сотрудник, занимающий должность ИТ архитектора. Как применить теоретические наработки архитектуры предприятия (Enterprise architecture), подходы к моделированию информационных систем, руководства по процессам управления ИТ к задачам и операционным процессам современной компании.

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

2. Роль архитектуры в процессах управления ИТ. Моделирование и инвентаризация ИТ-услуг и ИТ-ресурсов. Задачи архитектора в процессах управления изменения, управления релизами информационных систем, инцидентами, дефектами и проблемами.

3. Предпосылки возникновения сервис-ориентированного подхода в архитектуре:

- объектно-ориентированный анализ и проектирование информационных систем;
- открытые интернет-стандарты взаимодействия бизнес-приложений, SOAP и RESTful веб-сервисы;
- архитектура предприятия, средства управления бизнес-процессами, интеграция приложений.

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

5. Основные информационные системы организации. Финансовые и учетные системы. Системы управления персоналом, документооборота и коллективной работы. Приложения для поддержки взаимоотношений с клиентами, поставщиками и заказчиками. Интернет-сайт и корпоративный портал. Мобильные приложения. Технологии интеграции приложений. Сервисная шина предприятия, системы управления бизнес-процессами и бизнес-правилами, управление основными данными.

 

Надеюсь, основное учел. Буду признателен за добавления, советы, акценты и замечания!

В тумане облачных вычислений

Я подвергся очередному опросу относительно ожиданий от cloud computing или же, говоря русским языком, облачных вычислений. Думаю, эта тема изрядно надоела не только мне, но и большинству экспертов, занимающихся информационными технологиями.
Возможно, она уже актуальна для людей, занимающихся перепродажей серверного оборудования, но для отрасли программного обеспечения «облака» остаются пока в разделе размышлений о будущем. Сейчас про «облака» достоверно можно сказать лишь следующие:

ICAS-2011: Интеграция корпоративных прикладных систем

Недавно я выступал на конференции Интеграция корпоративных прикладных систем (ICAS-2011). Судя по высоким оценкам в анкетах участников конференции, готовился я не зря. Мой доклад об использовании Open ESB для построения композитных приложений был хорошо принят (выкладываю несколько слайдов)

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