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

О вреде готовых решений

Готовые решения развращают. Они приучают не думать, потому что зачем думать если уже есть готовое решение, то есть кто-то уже подумал за тебя? Самое любопытное заключается в том, что наличие готового решения иногда даже мешает поставить задачу, которую требовалось решить. Задача так и формулируется: "внедрить готовое решение". Точка.

Вспоминаю, как в одном из проектов консультант списал метрики процессов из известной книжки "Метрики для управления ИТ-услугами". Забавный получился результат 🙂

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

Арсенал "консультанта" сейчас довольно прост:

  1. Коробочный программный продукт. Там внутри и процессы уже прописаны, надо только с английского перевести. Но мы уже однажды перевели (студенты рулят), поэтому теперь у нас уже есть готовое решение!
  2. Книжка про метрики. Кладезь. В тех процессах, которые из коробки, тоже метрики есть, но здесь больше. И сразу с целевыми значениями. Готовое решение!
  3. Умение правильно выговаривать best practice. Best practice – это решение, которое мы уже однажды применили и смогли закрыть проект. Или решение, о котором мы прочитали в книжке и научились пересказывать. Нет нужды говорить – теперь это готовое решение!

Вендоры в той же цепи. Как увеличивать объем продаж? Нужно больше клиентов, больше партнеров чтобы с ними справиться, короче проекты чтобы увеличить количество продаж в единицу времени. Поэтому бренды со всем присущим им авторитетом продвигают готовые решения.

Учитывая, что огромное количество тендеров на предоставление услуг проводится по ценовому признаку, т.е. услуги покупаются как картошка или стулья, наличие готового решения и дешевого трудового ресурса – верный путь к успеху.

Заказчики, правда, потом удивляются: "Как так могло получиться?"

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

  • Готовые решения развращают

    Спору нет. Раньше, когда авто было дефицитом, советские люди напрягали все свои интерлектуальные силы и изобретательность, конструировали и собирали железных коней.
    А сейчас… Пошёл в автосалон, выбрал, сел и поехал… Народ тупеет и перестаёт проявлять смекалку.
    Плохо ли это или хорошо?

    Что касается готовых решений в обалсти ITSM, то все проблемы возникающине с ним, как мне видится возникают по следующим причинам:
    1. Готовое решение не сопровождается чётким и подробным опиcанием процесса, который реализован “по умолчанию”.
    2. Готовые решения не содержат подробного описания подготовительных работ и порядка их выполнения. (Например, что перед использованием, нало составить список Сервисов и забить их в систему).
    3. Покупатель готовой системы не учитывает, тот факт, что ему придёться поменять свою деятельность под те схемы, которые заложены в системе (и не готво к этому).
    4. И вытекающее из 3-го покупатель, при выборе готовой системы, не оценивает подойдёт ли ему та схема, что заложена в системе, сможет ли он изменить таким образом свою деятельность и т.д.

    А так хорошая идея, купил, поставил, запустил – быстро и сердито.
    Покупаем же мы стиральные машинки, в которых кто-то уже предусмотрел стандартные программы стирки, и ничего стираем…

    • К приведенным Вами пунктам могу добавить пятый и может быть самый серьезный: покупая готовое решение, заказчик испытывают иллюзию, что его (решения) будет достаточно, чтобы достигнуть нужный результат (лучше поддерживать пользователей, не получать таких рисков с изменениями, планировать расходы с учетом изменений в потреблении услуг и так далее). Прям как со стиральной машиной – не считая расходных материалов ее достаточно, чтобы сделать нашу одеждой чистой. И продавцы очень способствуют таким иллюзиям: “Зачем изобретать велосипед? Надо использовать лучшие практики, а они как раз и заложены в нашем решении. Примените его и управление ИТ услучшится”. А потом наступает удивление: оказывается, между стиральными машинами и результатами консалтингового проекта все-таки есть разница. Довольно серьезная.

      • Ну вобще-то, в идеале, если покупаешь готовое решение, то никакого консалтинга и быть не должно, разве что консалтинг по выбору этого самого решения. 🙂

        • Вот с этим, кстати, соглашусь: “1. Готовое решение не сопровождается чётким и подробным опиcанием процесса, который реализован «по умолчанию».” Фактически всегда описания нет. А если есть, то отвратительного качества.

  • >Примеры собственно тоже не очень, но некоторые — особенно “не очень”.

    Дим, я абсолютно точно помню: там примеры для вымышленного проекта некоей конкретное организации. О чем есть незаметная маленькая сноска где-то посередине книги 8) Что не повышает качества приведенных в примерах метрик (скажем так, качество метрик сомнительно), но все-таки оправдывает автора. Может, в этом вымышленном проекте в этой организации эти метрики были наилучшим выходом?

    А вообще, в целом я с постулатом “Коробочные решения – это безусловное зло” не согласен. Кто выбирает коробку с открытыми глазами (смотри тезис №3 в комментарии Павла) тот выигрывает. Кто заключает подразумеваемый социоконтракт вида “Купим коробку – процессы внедрятся”, проиграет в любом случае. Даже если он купит не коробку.

  • “А вообще, в целом я с постулатом «Коробочные решения — это безусловное зло» не согласен. Кто выбирает коробку с открытыми глазами (смотри тезис №3 в комментарии Павла) тот выигрывает.”

    Саша, в идеальном мире – согласен. В реальности – не видел ни разу. Уточню: под готовым решением я (как следует из текста)понимал не только коробочный софт, но готовое решение управленческих задач заказчика. Нет, конечно, если задача – регистрировать инциденты – велкам, коробок вагон (в т.ч. и бесплатных). Если задача – решить те или иные задачи в управлении – это миф.

    И по поводу открытых глаз эта ситуация почему-то ярко проассоциировалась у меня с названием известного фильма “С широко закрытыми глазами”. Так и выбирают 🙂

    • Управленческие задачи тоже разные бывают.
      если речь идёт о том, что у вас хаос, вы хотите хоть упорядочить свою деятельность, то тут как раз самое место применять бест, гуд, коммон и иные практики. И они вполен могут быть применены из коробки. И тут действиетльно коробка удобна и обеспечивает быстрые результаты (при правильном её применении).
      А вот когда у вас уже будет какой-то порядок, пусть не идеальный, пусть не на все 100% под вас, вы можете озадачится вопросами тонкой настройки повышать качество снижая издержки, обеспечивать 100% покрытие всех ваших ситуаций и прочее.
      Здесь действительно коробку применить нельзя, здесь надо подходить индивидуально.

  • “если речь идёт о том, что у вас хаос, вы хотите хоть упорядочить свою деятельность, то тут как раз самое место применять бест, гуд, коммон и иные практики. И они вполен могут быть применены из коробки. И тут действиетльно коробка удобна и обеспечивает быстрые результаты (при правильном её применении).”

    Сплошные “если”. Мое мнение – рынок _стонет_ от “готовых решений” и консультантов, не умеющих решать задачи. Основной инструмент работы консультанта – копипаст. Я вот в топике упомянул пример про списывание метрик из книжки. Это реальный пример из проекта. А вы говорите “если…”, “все зависит…”, “надо проанализировать…”. Никто ничего не анализирует. Впаривают и копипастят. Исключения единичны.

    Поэтому “готовые решения” – зло. По крайне мере здесь и сейчас.

  • э… коллеги, ну зачем вы опять так категоричны?
    Коробочные решения отлично работают там, где задачи и ответы к ним известны и стандартизированы – “если задача — регистрировать инциденты — велкам, коробок вагон”. И хуже подходят или совсем не подходят там, где задачи и решения нетиповые.
    Нетиповые задачи сегодня – это типовые завтра. Задача “регистрировать инциденты” тоже была нетиповой, и кто-то старательно изобретал этот велосипед. Сейчас мы его берем и используем при решении нетиповой задачи “организовать комплексную поддержку пользователей”. Наберемся опыта, набьем шишек, сформируем типовое решение и для комплексной поддержки. И будем его использовать в какой-то новой нетиповой задаче… Собственно, уже так и делаем.

    Зло – не в коробках. Зло – это когда частное решение, кое-как сработавшее один раз в одном месте, объявляется типовым и в таком качестве продается (и покупается). Так что рынок стонет не от готовых решений, а от полуфабрикатов, выдаваемых за таковые.

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

    Так что я удивленно радуюсь, снова и снова встречая заказчиков, которым в самом деле важен “настоящий” результат, а они с не меньшим удивлением наблюдают, как отдельные консультанты в самом деле решают их задачи.

    • Полностью согласен с Романом, сам хотел написать, но не успел 🙂

      Есть же та же коробка от Axios. Хорошая штука, но для своей аудитории. Если бы аудитории не было, не было бы и этого предложения (они ведь не вчера начали, успешный давний бизнес).

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

      “Зло — не в коробках. Зло — это когда частное решение, кое-как сработавшее один раз в одном месте, объявляется типовым и в таком качестве продается (и покупается).” – так и есть, сплошь и рядом. Когда в проектной документации забывают убрать слово “банк”, работая с ритейлом. Или ссылаются на какой-нибудь ДИТ, хотя такого подразделения никогда в компании не было…

      • Видимо с годами я утратил способность ясно изъясняться 🙂 Я не против типовых решений. Типовое решение это не шаблон для копирования, а подход к реализации. Если его разумно использовать, можно и риски снизить, и ресурсы на велосипеды не тратить. Уже обсуждали как-то: типовое решение – это входной билет, это _необходимое_условие_ для реализации типовых отраслевых процессов (наверно странно не иметь типовых операционных процессов управления ИТ). Но никак не достаточное.

        Готовое решение – это совсем другое. Это стиль продаж и выполнения проектов, который исходит из _достаточности_ типового решения. Который приводит к тому, что компетенция консультантов, выдвигаемых заказчикам на решение управленческих задач, ниже плинтуса. Потому что отправляют человека тиражировать, а не решать задачи. Который приводит к тому, что проект получается обреченным на провал на этапе его задумки, потому что цели определяются как внедрить “вот это волшебное готовое решение, т.к. вроде недорого”.

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

        • Это тебя печалит, как яркого представителя проектов типа “седина” (а вообще стремящегося делать проекты типа “мозги”). Консалтинг типа “процедуры” вполне имеет право на существование, и странно считать его девальвацией как интеллектуальной услуги.

          Классификация проектов т-ща Майстера, по памяти.

          • “Это тебя печалит, как яркого представителя проектов типа «седина»”

            Точно. И геморрой 🙂

          • Саша, приведенные мной примеры – это не “процедуры”, это за рамками классификации Майстера. Или как ты расцениваешь “консалтинг”, суть которого – выдать пачку незначащих документов, не решая задачи заказчика? Или ты делешь вид, что не встречал такого на практике?

            • Хотел написать длинный трактат, но понял, что всёможно сказать одной нетленной фразой:
              “Ах обмануть меня не сложно, я сам обманываться рад.”

              Может быть рынок предлагает ту химеру, что востребована покупателем? Может быть если бы Заказчики не наставивали на “готовых решениях подешевле” их бы на рынке и не было?

              • Ну, Павел… Это замкнутый круг. Можно бесконечно рассуждать про курицу и яйцо. Какой в этом смысл?

                А может быть можно что-то изменить? Например, рассказывая рынку, что можно и нужно по-другому. Например, показывая примеры – как это по-другому. Это конечно не даст мгновенного эффекта. Но может быть это шанс немного больше уважать себя завтра.

                • Дмитрий, ни какого замкнутого круга. Лично для меня, всё понятно, есть “низкие” потребности рынка и торговцы, которые их используют себе во благо.
                  Можно ли изменить или нельзя, я вам не скажу, не прорицатель. Хотя сильно в этом сомневаюсь, ведь вера в чудодейственные пилюли которые за один раз все болезни лечит всё ещё сильна в народе, хотя “уж сколько раз твердили миру…”. Это же мечта, мечту не отобрать…
                  Ну а попробовать изменить – дело благородное, если удаётся сочетать благородство и возможность прокормиться, это замечательно. У меня вот не получается.

              • Десять дней назад товарищ и соратник ИТ Скептик очень хорошо выразился на схожую тему:

                “Anyone who believes they can buy a plug-and-play CMDB from a vendor gets what they deserve”

                “Любой, кто думает, что может купить у вендора коробочную CMDB, получает ровно то, что заслуживает”.
                🙂

      • Sinan

        Всё то что затронуто Вами, об этом думает каждая зрелая компания.

        Готовое решение – это очень выгодная штука для бизнеса
        Готовое решение – это работа на уровне обезьяны, где уже не требуются высококвалифицированные специалисты. Возьмите в пример Scoring программы. Все те tools-ы относящие к Риск менеджменту. Потому и выгодна для бизнеса.
        Готовое решение – это стандартизация. Это то что смывает конкурентоспособность. Это это что делает компанию А и Б одинаковой. Причём Б это отстающая компания, которая на опыте внедрения компании А, в более краткий срок внедряет готовый продукт у себя.

        Про это очень детально и интересно пишет Николас Карр.

        • “Готовое решение — это очень выгодная штука для бизнеса”

          Sinan, все, что я могу сказать по этому поводу, Вы видимо не очень внимательно читали пост и коменты. А впрочем может быть я не очень внятно писал.

          Николаса Карра конечно читал. Но сейчас речь не об этом 🙂

          • Sinan

            Я Вас в чём то осуждаю?
            Я добавил своё по теме.

            • “Я Вас в чём то осуждаю? Я добавил своё по теме”

              Я как раз и пишу выше, что с моей точки зрения Вы добавили своё не по теме. И конечно никаких обид 🙂

              • Sinan

                ))) Шикарно, согласен.
                Я охватил все готовые ИТ-продукты для остальных сфер.

  • Роман,
    как всегда, наиболее близко к истине )

    • Тперь я понял о чём не договаривали ангенты Скали и Малдер.
      Полностью их лозунг должен звучать так:
      “Истина! Где-то рядом Роман Журавлёв!”
      🙂


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM