Абсолютно случайный разговор с коллегой-процессником, слушавшим курсы по "одной известной модельке процессной" (с) от Карнеги-Меллон. И в разговоре среди обсуждения моделей, наборов процессов, недоработок этих моделей и персоналий, любящих на это закрывать глаза всплывает тема коммерциализации и связанной с этим постепенной деградации модели.
И тут я залип в размышлениях. А почему, собственно, явное ухудшение самой модели ITIL v3 и опутывающих его процессов (сертификация софта, сертификация людей) я рассматриваю как случайность, как ошибку конкретного персонала itSMF, OGC, APMG? Возможно, это системный принцип. Пока некоммерческое сообщество (делающее модель, набор практик, проект стандарта) действительно не ставят перед собой вопросов получения прибыли - модель развивается. Но рано или поздно вопрос монетизации всплывает - и определенные люди уходят, приходят другие - они успешно справляются с задачей монетизации, но модель-то уже того. Начинает постепенно сползать в яму, а затем и в ямищу. Много и абстрактно-бесполезно думал. А вообще - очень красивая гипотеза.
ps. Может, у кого-то есть подтверждающие, обратные примеры на основе сообществ и моделей 5-15 летней давности?
пятница, 25 июня 2010 г.
О моделях, сообществах и коммерциализации
Подписаться на:
Комментарии к сообщению (Atom)
7 комментариев:
К сожалению упадок это естественная фаза жизненного цикла. Еще один, может даже более яркий пример, заметный, в отличие от ITIL, и непрофессионалам в данной области - разивитие стандартов middleware, разабатываемых OMG, а точнее - CORBA. Блестящий по своему содержанию в первых версиях, но выродившийся в нечято громыхающе-неимплементируемое - CORBA Component Model. Идея была хорошая, но в определенный момент ставшая в силу своей комплексности практически нереализуемой. Сложность другого стандарта - EJB (Enterprise Java Beans) стала одним из факторов того, что широкие массы разработчиков статли использовать альтернативные технологии. (хотя в случае Enterprise Java сыграло свою роль и наличие огромное массы специалистов php-шников, которые не очень любят инвестировать свое время в фундаментальные вопросы - будь то архитектура приложений или процесс разработки - низкий порог вхождения в технологию автоматически сыграл против компетенций и стандартов).
Из обратных примеров - COBIT. Тут как раз удивительный exception, имхо (и по текущему поколению 4.* м по тому. что я видел из относящегося к COBIT 5). Более взвешенного стандарта/фреймворка в нашей индустрии еще надо поискать. Наверное. еще Open Group TOGAF 9 с каждой версией становится все более отточенным, а не громоздким.
Спасибо за комментарий, Сергей.
То есть, я правильно понимаю, вы считаете - что это проблема конкретных людей, архитекторов модели? (случай с разработчиками php можно исключить, думаю).
Если что, я на примерах ITILv3, CMMI Serv.
eTOM 8 - набор описаний бизнес процессов для телекоммуникационных компаний (часть стандартов организации TM Forum). Весьма живая вещь. Даже странно, что слабо упоминается в кругах ITSM-щиков. В последнюю версию они даже включили некие мостики для ITIL (в базовые уровни).
eTom не очень подходит. По моему глубокому убеждению эта штука изначально разрабатывалась под продвижение телеком-продуктов, что успешно и выполняется. И проектировалась с прицелом именно под эту цель.
Кстати, он очень громоздкий. Но это не минус, это скорее плюс - в рамках вышесказанного, разумеется.
Александр, я думаю что проблема в сочетании уровня экспертов, создающтх стадарты и глубины связи их с R&D компаний с т.з. реализуемости стандартов, а также непосредственного практического опыта экспертов, помогающего не "уплыть" в идеальную академическую модель. А это зависит от самой модели деятельности сообщества, отвечающего за разработку стандарта.
А вот eTOM действительно хороший пример удачного и главное - работающего фремворка, потому что его создают практики и на него серьезно влияют реальные игроки рынка, задающие соответствующие тренды и для которых жизненно-важна унификация соответствующих процессов в силу требования интегрируемости телеком-бизнесов, каждый из которых по отдельности нежизнеспособен и только сосуществуя вместе по одним и тем же правилам игры они составляют современную единую телеком-инфраструктуру.
Я бы сказал, что CobiT пока справляется с "наследием темного прошлого". То, что описывается сейчас Александром когда ITIL перекраивают во что то непонятно в угоду сиюминутным интересам наблюдалось в CobiT v2 - v3 в 98-2000 годах. "На слуху" были "Проблемы 2000 года", "Информационная безопасность", "Риски" ... И в версии 3.0 наступил серьезный перегиб процессной модели под критерии "безопасности". Очень хорошо, что в 4 версии все более-менее наладилось, хотя с "наследием ..." и в нем есть где побороться.
Отправить комментарий