Обсуждение

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

Видимо, переход к сервисной модели ОТ продуктовой - сильно не то же самое, что ОФОРМЛЕНИЕ сервисной модели (внутри или в аутсорсинг). Например, переход к сервисной модели от продуктовой не влияет на utility продукта (полезность бетона или дороги известна и не изменится), но влияет на warranties.

Я тут обсуждаю не собственно предложение, а "внутреннее отношение" производителя -- считает ли он, что производит сервис, или считает, что он "отгружает продукцию". Когда IT-сервисов еще в проекте не было, гуру менеджмента с удивлением заметили, что те бетонные и металлургические заводики, которые внутри себя считали, что они осуществляют сервис для своих клиентов, а не "отгружают продукцию рынку", явно имели конкурентное преимущество -- просто из-за того, что "вставали в сервисную позу". Обсуждалось тогда (это работы примерно десятилетней давности, минимум) это вообще без привлечения понятий "риск", "процессы", "дополнительные услуги к продуктам". Просто люди заметили, что а) любое производство можно представить как сервис, и б) после того, как люди пытаются "служить" (речь идет о ментальной установке на служение), дела в такой фирме идут лучше. Ты же ставишь совсем другие вопросы, исходящие из приложения первых глав ITIL v3 service strategy к неайтишным инфраструктурам. Это другой анализ, и он, конечно, должен быть сделан. В самом тексте ITIL приведены картинки, где показываются самые разные варианты структурирования сервиса с точки зрения собственности на материальные ресурсы и продукты. Там много-много разных вариантов, а если учитывать (что обязательно требуют) развитие/инвестиции в новые мощности, то вариантов становится еще больше.

Непонятно, что ты имеешь ввиду под "переходом к модели" -- простройку процессов и прихват знаний в соответствии с какой-нибудь формальной сервисной организационной моделью? Это вполне может повлиять на utility в том числе (при первых же попытках записать в каталог наименование продукта). Одни мои знакомые мусорщики сказали, что сейчас у них услуга -- "вывоз мусора", но она клиентов не слишком удовлетворяет, ибо им нужна услуга "чистота". Согласно сервисной модели, это (utility) -- первое, с чем нужно разбираться. А затем, конечно, идет полноценная разборка с warranty (чего при продуктовой модели почти не происходит).

Там самое интересное -- это развитие. Если ты отгрузил продукт, то дальше можно только покупать новый продукт. Если ты отгружаешь сервис, то время от времени идут улучшения этого сервиса, апгрейды. Это совсем другой заход, и он мне представляется главным. Ни одно событие в сервисе не является последним. Если ты поставил 5 чушек чугуния в продуктовой модели, то это "поставка". Если то же самое в сервисной модели, то поставка этих чушек -- небольшая часть истории партнерства с клиентом. Этих чушек в сервисной модели будет еще много, и еще более высокого качества и еще более вовремя.

Про сервисное мышление и про переход к нему хорошо написано в Реинжиниринг Корпорации (которую Вы как-то упоминали). А вот в формальных описаниях обычно ни слова не пишут зачем это нужно. Типа тупо делайте и все тут. При этом легко напороться на мину, т.е. я могу нарисовать value chain и она даже будет иметь отношение к реальности, но у меня совершенно нет уверенности, что она решает какие-то существенные проблемы и не вносит при этом новые - гладко было на бумаге, да забыли про овраги. Возможно много вариантов абстракции отношений между сторонами, но как из них выбрать правильную? Формальные описания постулируют, что любая формализация по определению правильная. А если они не соответствуют реальности, то тем хуже для реальности типа :). В случае с бетоном, есть известный случай, что какая-то контора оборудовала водителей бетономешалок спецтерминалами и сделала специализированную доску объявлений "разведенного бетона". Т.е. раньше если нужда в уже разведенном бетоне по каким-то причинам пропадала (клиент отказывался), то его приходилось утилизировать, а затраты так или иначе перекладывать на заказчика и общество. На лицо неэффективность. Теперь, компания могла быстро находить потенциальных заказчиков на внезапно образовавшиеся излишки и использовать их с пользой. Понятно, что в жесткой схеме "утром деньги, вечером стулья" это невозможно сделать. Это пример полезного сервиса. Понятно, что такую схему мог придумать только тот, кто хорошо знаком с бетонными реалиями (и с новинками ИТ). Но мне трудно представить, что ее мог придумать человек, ознакомившийся с формальным описанием сервисного подхода.

"Сервисный подход -- это обобщение системного подхода" - это достаточно смелое утверждение :) Все-таки системный ближе к курице, а сервисный - к яйцу! Не читали? http://community.livejournal.com/k_management_ru/22192.html

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

Формальное описание сервисного подхода нужно только в одном случае: если вы собираетесь что-то там в сервисной организации улучшать, а для этого вам нужно наладить обсуждение. Для всех остальных случаев сороконожке лучше не знать, как она бегает -- если у нее не стоит, конечно, задачи выиграть гонку у других сороконожек.

Это видимо, действительно одна из серьезных проблем, как гармонично перейти от абстрактного к конкретному. Упростить, но не исказить. Схемы (1,2,3...и т.д.: функция, процесс, сервис, структура и т.д.) и контекст (внешний и внутренний). Хватит ли этого для объяснения, понимания и управления? А книга очень даже ничего, рекомендую. Как раз от теории плавный переход к конкретным кейсам. Есть модели целого народа-племени, отрасли, фирмы.... Забавны перекликания с ГП. Очень верная мысль, как разумно дети ищут путь из лабиринта: всегда, по возможности лучше двигаться от выхода (конечной цели), постепенно выстраивая путь к текущему месту и ситуации. Попытки избавления от хаоса и сложности благодаря итерационному подходу к познанию и его моделированию.

Ну это уже сегодня общие места: системность, итерационность, движение по процессу от его выхода. Все эти идеи даже не двадцатилетней давности... Дело не в недостатке подобной литературы. Дело в умении применить все эти идеи на практике в конкретной организации, в которой невозможно заставить 2000 или 200000 человек ее сотрудников начитаться подобной литературы до такого состояния, что они сообразят, как эту "итерационность" применить в их производственной или административной жизни. Так что я уж пока ITIL почитаю. Трудное чтиво, но практическое.

ITIL - дело хорошее, кто же спорит. 3-ю версию изучаете? Мы у себя в организации (как раз очень приличной по размеру и распределенности http://www.cbr.ru/) с http://www.itexpert.ru/ сотрудничаем на эту тему. Дело, однако, в том, что человек и социум - это такой зверь, который не помещается целиком в клетку технологичности и голой логики. Ему эмоции подавай, красоту и гармонию. А этого в ITIL не проходят. Современный системный подход целостней и ближе как раз простому человеку. Общую культуру на нем проще построить, а значит общее видение и движение к общим целям.

Вестимо, что ITIL -- процессный кусочек. Нужен еще и коллаборативный кусочек (и именно в нем всякие эмоции и гармонии). Это мы понимаем, и этим занимаемся.