Портал №1 по управлению цифровыми
и информационными технологиями

Разрабатывать или покупать приложения: книжный ответ

Опубликовано 17 октября 2012
Рубрики: IT Governance, ITIL, ITSM, Источники знаний, Сорсинг, Эксплуатация ИТ
Комментарии

То ли делать нечего, то ли коллеги застыдили, а я опять открыл умные книжки, и снова хочу на примере продемонстрировать, что в ITIL гораздо больше полезного, чем представляется скептикам.

Эпиграфом к ITIL Service Strategy 2007 была цитата Вильяма Д. Грина из Accenture: 

How do you become not optional?

Её вольно можно перевести так: "Что нужно делать, чтобы без вас не смогли обойтись?". Фраза настолько откровенно и ёмко позиционировала саму библиотеку и описывала чаяния целевой аудитории, что в 2011 году Девид Кэннон, переписывая Стратегию Услуг, вычеркнул её со всем старым вступлением (а многие русскоязычные авторы – еще нет).

Но далее по новому тексту идея сохранена. Выбор у каждого предприятия простой: "Build vs Buy". Что делать с информационными технологиями – покупать или делать самим? Что выгоднее в краткосрочном и долгосрочном периодах?

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

  1. Своё ПО устарело, а решения вендоров регулярно обновляются.
  2. Архитектура своего ПО была придумана давно, когда никто и подумать не мог про <подставьте сюда современные бизнес-модели или новые требования законодательства>.
  3. Своё ПО устарело вместе со своими разработчиками.

Удается успешно и в короткий срок осуществить этот переход, по моему опыту, очень немногим.

Почему?

ITIL говорит, что вместо вышеперечисленных соображений, решения должны быть основаны на следующих ответах (по Милгрому и Робертсу):

  1. Требуются ли для обслуживания данного приложения узкоспециализированные ресурсы? Если это ПО будет выведено из эксплуатации, эти ресурсы станут ненужными? Если да, то скорее выгодна передача этого кусочка автоматизации внешнему вендору (аутсорсинг).
  2. Приложение используется редко или от случая к случаю? Если да, то скорее аутсорсинг.
  3. Требуется ли для разработки и поддержки приложения глубокое понимание какого-либо бизнес-процесса, даже если оно используется редко? Если да, то скорее стоит оставить её внутри организации (инсорсинг).
  4. Насколько сложно устроено приложение? Подвержено ли оно частым изменениям? Если нет, то аутсорсинг.
  5. Сложно ли описать достаточную степень производительности приложения? Если да, то инсорсинг.
  6. Сложно ли измерить производительность приложения? Если да, то инсорсинг.
  7. Насколько тесно приложение связано с другими системами и бизнес-активами? Увеличит ли передача приложения на аутсорсинг сложность взаимосвязей и сложности интеграции? Если да, то инсорсинг.

Как мне кажется, отличный список вопросов, особенно пункты 5 и 6, которые прямо передают привет всем, кто озадачился процессом SLM.

Давайте попробуем в комментариях собрать статистику ответов и кейсов перехода от инсорсинга к аутсорсингу ПО. Особенно интересны системы, критические для бизнес-модели (автоматизация закупок, продаж, операционной деятельности).

Кстати: Сразу в открытом интернете я не нашел фундаментальной литературы на тему транзакционных издержек, кроме, пожалуй, исследовательского материала Питера Кляйна The Make-or-Buy Decision. Всего 30 страниц, считая список литературы, очень рекомендую, язык простой. В частности, ссылается Кляйн и на книгу Милгрома и Робертса Economics, organization, and management, На ту же, что и ITIL.

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 6

  • Георгий

    Константин, не хочу разочаровывать, но список предложенный не помогает с вопросом Build or Buy. Приведенный список (не полный кстати), скорее отвечает на более расширенный вопрос, который теоретики аутсорсинга предлагают сейчас в качестве альтернативы традиционному – “Build, buy or rent”, т.е. разрабатывать свое, покупать готовое или арендовать готовое с акцентом на арендовать/не арендовать

    • Константин Нарыжный

      В той истории, к которой я пытаюсь приложить эту логику (безусловно очень широкую), акцент как раз на “делать или не делать самим”.
      С точки зрения приобретения ПО выбор “арендовать\покупать” по-моему, не стоит, ведь используя стороннее ПО, вы лишь однажды “купите” лицензию, а потом, в виде оплаты техподдержки, долго будете “арендовать” тамошние ресурсы разработчиков, тестировщиков, маркетологов и т.д.
      Георгий, не разочаруете, если сможете дополнить список из теоретиков. Спасибо!

      • Георгий

        С точки зрения “приобретения” ПО, конечно вопрос не стоит, потому что приобрести – это вариант Buy 😀
        Приложение можно “купить” (готовое, допилив функционал под себя), можно разработать самим (держа у себя аналитиков, разработчиков, тестировщиков, внедренцев, техподдержку, менеджмент данного проекта итп), можно арендовать готовое (тут уже сильно допилить не получится). Это и есть теория аутсорсинга приложенная к случаю некого программного приложения

        в теории, когда компания решает для себя использовать ли аутсорсинг она отвечает сначала определяет для себя цель подобной передачи (они могут быть разные), а потом, с учетом этой цели, отвечает на такие примерные вопросы:
        1. Вопрос компетенций/ресурсов – какие компетенции и ресурсы будут находится за пределами компании в случае аутсорсинга, не являются ли эти ресурсы уникальными и трудновосполнимыми и не составляют ли основу конкурентных преимуществ компании (да, как правило, некие уникальные ресурсы всегда составляют конкурентное преимущество, но памятуя, что мы пишем про ИТ, я решил уточнить теорию немного, в ИТ бывает и наоборот :))
        2. Вопрос финансов – будет ли совокупная стоимость владения аутсорсинговым решением дешевле стоимости владния своим (здесь надо помнить про скрытые затраты для инсорса и транзакционные затраты для аутсорса)
        3. Вопрос бизнес-процессов – насколько готова компания менять существующий бизнес-процесс для перехода (не обязательно полного, даже пусть частичного) на аутсорсинг, не является ли данный бизнес-процесс критичным для успешности компании, как будут минимизироваться риски в данном случае
        4. Вопрос безопасности – не является ли часть бизнеса отдаваемая на аусторсинг чувствительной к вопросам безопасности, не несет ли это в себе потенциальной угрозы
        5. Правовые вопросы – не является ли передача данной части бизнеса на аутсорсинг нарушением государственных или отраслевых законов и/или стандартов
        6. Вопрос управления – каким образом планируется управлять аутсорсинговыми контрактами, поставщиками, проектом аутсорсинга в целом

        Больше не вспомнил так навскидку

        • Константин Нарыжный

          Упс, опять в термины упёрлись
          Хах, ну да, с “приобретением” я промахнулся в логической конструкции. Имел в виду “обретение”, acquiring. =)

          В вашей терминологии, c точки зрения “допиливания”, я не могу провести четкой границы между buy и own.
          Мы ведь с вами об одном и том же типе ПО, да?
          Когда внутри компании создаются “центры знаний по …”, нанимаются разработчики под конкретную платформу и т.д. Такой “buy”
          для меня практически равен “own” в изначальной постановке. Лицензии и дистрибутив – вот что покупается, а в остальном это приложение станет самым настоящим own, поэтому ваши вопросы не решаются однозначно:
          1. Компетенции – зависимость от “допиливальщиков” такая же что и от “своих” программистов
          2. Финансы – в этом то и суть выбора, включающая и ваши и ITIL-овские пункты)
          3. БП – ну про это и в посте выше
          4. Я склонен думать, что в связке с вопросом 5 риски безопасности примерно те же, что и со своими разработчиками. Дело в длине языка.
          5. Я с трудом представляю себе такое ПО, которое было бы запрещено отдавать на аутсорсинг. Разве что платформа электронного правительства?
          6. Вот наверное самое существенное. Затраты на управление контрактом против затрат на управление персоналом, который к бизнес-модели отношения не имеет.

          Спасибо, что вспомнили список. Где можно подробнее почитать, не подскажете?

          • Pavel Solopov

            C ПО всё несколько сложнее, как мне видится. Можно:
            1. Купить коробку и кастомизировать её своими силами.
            2. Купить коробку и кастомизировать силами подрядчика.
            3. Разработать софт своими силами.
            4. Разработать софт силами стороннего подрядчика.
            5. Сопровождать софт своими силами.
            6. сопровождать софт силами стороннего подрядчика.
            Перечисленные пункты могут замысловато сочетаться и пересекаться. 🙂

            Ну и ещё есть вариант:
            7) Купить софт и не кастомизировать её, а подстроить под неё свои процессы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.
;