Service Knowledge Management System

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

Читать далее Service Knowledge Management System

Gartner: Projects Today, “Change Operations” Tomorrow

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

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

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

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

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

Краткий обзор статистики посещений

Иногда я просматриваю статистику своего блога. Разбираясь в том, какие записи вызвали наибольший интерес за II квартал, я обнаружил наибольшее количество просмотров у записей:

Читать далее Краткий обзор статистики посещений

Кнопка «Feedback» в бизнес-приложениях

Рассматривая примеры приложений в Oracle Application Express наткнулся на одну интересную фичу. В коробке с Oracle APEX есть приложение для командной работы «Team Development», включающее в себя такие базовые функции, как планирование, управления задачами и требованиями(фичами), баг трекинг и т.п. Одним словом, довольно нормальное такое приложение для RAD разработки, ничего особо примечательного, если бы не одна вещь. Если мы запустим пример приложения, разработанного на Oracle APEX, то увидим в правой верхней части сайта кнопку «Feedback».

При нажатии на ссылку открывается неприметное окошко с предложением оставить комментарий, зарегистрировать ошибку или предложить улучшение. «Feedback» – традиционная функция для сайтов и инновационная для бизнес-приложений.

Т.е. бизнес-приложение изначально интегрировано с bug tracker-ом разработчика. В корпоративных информационных системах такое не принято. Много лет и ресурсов компании потратили на создание единого HelpDesk, в котором не очень высоко оплачиваемые специалисты дают не всегда правильные ответы на совсем неправильные вопросы пользователей. На большом масштабе получается хорошая экономия. Однако и отрицательные последствия централизации этой функции велики. Для большинства пользователей быстро найти нужно человека в ИТ, который мог бы решить проблему – задача неимоверно сложная. Чтоб твои вопросы решались надо быть директором, а лучше – вице-президентом. Похоже, маятник начал движение в обратную сторону. И уже разработчики приложений заинтересованы в установлении прямого контакта с конечным пользователем. Особенно это актуально для внешних разработчиков. Ведь если баг – это дополнительная неоплачиваемая работа, то расширения функционала – новый заказ. При этом, вся бюрократическая машина внутрикорпоративного ИТ остается не при делах. Маркетологи это называют каналом взаимодействия с клиентом. Тенденция чем-то похожа на то, что в сфере управления бизнес-процессами называют Social BPM.

Настоящие акулы ИТ аутсорсинга не должны упускать такие возможности!

Почему ИТ-сервисы должны базироваться на архитектуре

На протяжении последних десяти лет ИТ архитектура и управление ИТ-сервисами(ITSM) следуют параллельными курсами. Не то чтоб они не пересекаются, пересекаются они на каждом шагу, я бы даже сказал, не пересекаются, а скорее сталкиваются, высекают друг из друга искры и снова расходятся на безопасное расстояние. При этом оба обозначенных направления изначально не являлись целостными и крайне друг в друге нуждаются. Проблема ИТ архитектуры заключается в её статичности. Архитектурные модели, вырванные из процессов ИТ, не актуализируются и довольно быстро устаревают. Архитекторам, зачастую приходится заниматься тем, что Гради Буч назвал software archeology, раскопками утраченных знаний о том, что представляет собой ИТ система и как она работает. В свою очередь, ИТ процессам очень не хватает четкой классификации объектов и отношений между ними. Определяемые ITIL понятия ИТ-сервис и конфигурационная единица(КЕ) не особо конкретны. Любое существительное можно назвать КЕ, однако сколь либо стандартизированных классификаторов КЕ не существует и организациям их приходится придумывать самостоятельно. С ИТ-сервисом ситуация не лучше. Про него по большому счету известно то, что он предоставляется и то, что он обладает(или должен обладать) соглашением об уровне сервиса (SLA). Попробуем «подружить» архитектуру информационных систем и управление ИТ-сервисами Читать далее Почему ИТ-сервисы должны базироваться на архитектуре

Ожидания, разочарования и прогнозы 2010/2011

Под бой курантов принято подводить итоги прошедшего года и строить планы на будущее. Следуя этой традиции я проведу краткий обзор того о чем писал в своем блоге и того о чем намерен писать.

Безусловным хитом года 2010 стала тема адаптивного кейс менеджмента. Adaptive Case Management это разумная середина между излишней наукообразностью BPM подхода и отсутствием таковой у подхода ECM. Читать далее Ожидания, разочарования и прогнозы 2010/2011

Релизы и версии

Как и во многих крупных компаниях, наш корпоративный ИТ ландшафт состоит из информационных систем, таких как система управления отношениями с клиентами (CRM), система самообслуживания, биллинговая система и т.д. Всего их в CMDB насчитывается несколько сотен. Каждая система включает в себя несколько программных компонент. Это и базы данных и JEE приложения, толстые клиенты и web-интерфейсы. До пришествия виртуализации каждая система развертывались на своем наборе оборудования. Впрочем, и сейчас основные системы развернуты на закупленных специально для них серверах.

Не удивительно, что ИТ система является основным элементом управления. К ИТ системам привязываются запросы на изменения (Request for Change, RFC). Системы являются основной единицей процесса управления релизами. Т.е. для каждой системы развивается своя ветка релизов. Все планирование, разработка, тестирование и развертывание ведется в границах систем. Версии приложений попросту совпадают с релизами. Мы не уникальны. Многие компании развивают свою ИТ-инфраструктуру примерно так же. Но в какой-то момент это становится проблемой. Сначала проблемой ИТ архитектуры, а вскоре и проблемой всего ИТ.

На днях листая перед сном ITIL я пытался найти ответ на вопрос почему релиз может включать в себя только одну ИТ систему. Честно говоря, в явном виде такой рекомендации я не нашел. В чем недостатки привязки релиза к одной конкретной ИТ системе? Все очень просто. Традиционный цикл выпуска программного обеспечения ограничивается фазами анализ->проектирование->разработка->тестирование->развертывание. Однако в большинстве современных компаний изменения в ИТ носят комплексный характер, затрагивают сразу несколько систем (см. примечание). Такие работы, как согласование интерфейсов, интеграционное тестирование, конфигурирование приложения (это когда вместо абстрактных интерфейсов, администраторы прописывают реальные ip-адреса web-сервисов и connection strings баз данных), пользовательское тестирование (UAT), разработка архитектуры, в конечном счете =) и управления конфигурациями – остаются за бортом процесса.

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

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

Заказная разработка vs. коробочные решения

Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.

Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:

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

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

Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется

Еще несколько слов про CHG

Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.

Читать далее Еще несколько слов про CHG