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

Развязали руки? Держите себя в руках!

Опубликовано 6 октября 2010
Рубрики: ITIL, ITSM, Service Desk, Обо всём на свете, Практика и опыт, Технологии, автоматизация, ПО для ITSM, Управление изменениями, Управление инцидентами, Эксплуатация ИТ
Комментарии

Еще недавно в России было не так много средств автоматизации ITSM процессов. Я, например, начинал проектировать процессы имея ввиду, что автоматизировать их придется на HP OV SD. Т.е. процессы конечно же проектировались, и отличались друг от друга, и подгонялись под задачи и возможности заказчика, но все равно на них (на нас при проектировании) давило то, что продукт не многое позволит. И поэтому полет фантазии приходилось загонять в угол и откладывать на потом.

Что мы имеет теперь? Руки развязали, все продукты, по заявлениям производителей, супер-мега-гибкие движки – делай что хочешь, никто тебя не ограничивает. Сбылась мечта, можно доставать из углов идеи для процессов. Вот только надо ли? Стоит ли усложнять процессы дополнительными мульками на все случаи жизни, или остаться в рамках, простых, понятных процедур, которые и без навороченных алгоритмов дадут результат. 

Вот простой пример: раньше сроки решения инцидентов считали себе по Impact, Service и SLA (связка сервис, пользователь, уровень сервиса) и все было прекрасно, обходились. Сейчас появилась возможность накрутить сюда еще зависимость от региона пребывания пользователя и массы других параметров. С одной стороны здорово, этого многим не хватало, с другой стороны появились дополнительные усложнения, в виде необходимости поддерживать в актуальном состоянии местоположение пользователей, заводить новые регионы и т.д. С точки зрения процесса появилась необходимость согласовывать дополнительные параметры, контролировать их. Появилось множество точек для возникновения ошибок и неточностей. И это только начало. Проектировал недавно процесс управления изменениями, ох, сколько там всего можно предусмотреть и наделать с развязанными руками, мммм…. Как представлю, дрожь берет.

В итоге, если увлечься созданием процесса, который предусматривает все и на все случаи жизни, а потом еще и автоматизировать это. Можно свести на нет эффект от его внедрения.

В общем, для себя я сделал вывод, что руки развязали, но надо держать себя в руках.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

  • Дмитрий Исайченко

    Камрад, +1. Но ты ведь не хотел бы вернуться в прошлое, не правда ли? 😉

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

    Надо просто фантазировать, понимая что ты хочешь получить. Это как режиссер, снимающий фильм. Долгое время возможно только он один и понимает к чему ведет. Его задача, ответственность – непросто “поработать”, а “сделать”. Фантазия + дисциплина.

    • Георгий

      Браво! :)))))
      “Фантазия + дисциплина”, это 10 баллов, я так живо себе это представил :))))))))))))))))))))

  • Евгений Шилов

    Вот и я же про то же 🙂

  • Олег Скрынник

    Интересное наблюдение. Меньшие ограничения средства автоматизации приводят к бОльшим проблемам.

    Некоторые известные компании практикуют “типовые” процессы, не зависимо от исполнителей, но там-то причина другая – наоборот, софт поменьше трогать, чтоб не развалился.

    • old fuddy-duddy

      А некоторые к коробке с софтом прикладывают “коробочное” описание процесса – продавцы волшебных кнопок. И ведь у них покупают!

      • Олег Скрынник

        Покупают ли?

        Продают – это да, но ведь любой, кто серьёзно занимался автоматизацией любого бизнес-процесса в компании понимает, что шаблоны и коробки всё равно придётся доделывать и дотачивать, несмотря на весь best practice и красоту кнопок.

        • Павел Солопов

          А что плохого в коробке? Если в коробке действительно нормальные конкретные Лучшие (или хорошие) практики заложены, а не размазня многостраничная. Если действительно это опробированно на практике и показало результат, то почему бы вам и не использовать? особенно если ваше предприятие не собирается получать бизнес-преимущества из уникальности своих процессов поддержки ИТ.
          Только надо быть готовым наступить на горло своей песне. И не только песне ИТ-ишников, но зачастую песне бизнесс-боссов, которые привыкли, что бы им отчёт только на бумажке, чтобы Катю, Машу, Петю обслуживали быстро, а Глаашу чуть медленее, но не всегда, только в конце месяца и т.д.

          Если люди построили дом из брёвен, сделали в нём дверь, чтобы входить, и окно, чтобы свет был. То можно перенять их опыт, и быстро жить в тепле и уюти, хотя может это и не будет похоже на вашу прежнюю юрту. А можно начать дом под свою юрту подгонять, окна не делать, вместо двери шкуру, в крыше дырку по центру (ну и пусть печка есть)…
          Живём мучаемся, ругаем тех, кто дом придумал, мечтаем о доме в котором можно будет юрту построить. Ведь мыже без юрты никуда, мы в ней родились, в ней выросли…

          • Андрей

            вот к этому +1:)

          • Дмитрий Исайченко

            1. Очень умозрительный пост – про дом, бревна и окна. А в реальности у _всех_ (100%) изестных мне коробок есть серьезные проблемы в функционале, т.е. что-то сделано хорошо, а что-то очень странно и не сильно применимо к проектной практике (по крайней мере с моей точки зрения). Это как если бы был дом из бревен и окно и даже дверь, но пол – под углом 30%. Т.е. можно конечно и так, но как же это неудобно 🙂

            2. Более того, коробки по определению имеют четкие функциональные ограничения: вот это мы умеем (например, INC), а вот это – умеют другие, а мы не причем (например, внутренний документооборот). “Некоробка” позволяет Вам эти границы перодолевать. А коробка – это best practice (с учетом вопросов выше) “от сих до сих”. Как у Райкина: “Я тут пуговицы пришиваю. К пуговицам претензии есть?”

            3. Далеко не все известные мне заказчики мечтают о юртах при наличии нормального дома. Бывает как раз наоборот. И я несколько раз наблюдал, как заказчику предлагают новую коробку словами “Тут все по ITIL. Вы что, против ITIL?!” Видимо, это в ITIL прописаны жесткие схемы workflow, которые нельзя менять (а то хуже будет). Это в ITIL указано, что классифицировать объекты нужно именно так и нельзя по-другому. Это в ITIL определены фиксированные алгоритмы поиска и привязки SLA. Это в ITIL сказано, что задание, как универсальный объект, а не в составе инцидента, делать нельзя из религиозных соображений. В ITIL сказано, что иерархия компаний должна иметь фиксированную глубину 3 уровня, а если у вас не так, то это неправильно. ITIL настоятельно рекомендует рассчитывать срок обработки на базе приоритета и делать многие-многие другие глупости. Даже писать устал 🙂

            • Павел Солопов

              Ну что Вы, Дитрий, в самом деле, не даёте даже словоблудием поразвлекаться в пятницу-то. 🙂

              Ну а если по делу. То, как я говорил, описание ПРАКТИК прилагающееся к коробке должно быть конкретным, подробным и полным. Начиная от того, какие роли надо назначить, какие группы сформировать и т.д. И заканчивая ролевыми инструкциями каждой роли. (Описание типа “в соответствии с ITIL” не пойдёт, также как не пойдёт описание процесса крупными мазками “по квадрату на роль”.) Только в этом случае данный продукт можно назвать коробочным.
              Не знаю, есть ли такие продукты в реальности, не приходилось слышать много отзывов, возможно это недостижимый идеал.

              Ну и конечно же коробку надо тщательно подбирать перед покупкой, как вы выбираете какой-нибудь утюг, или микроволновку.

              • Дмитрий Исайченко

                > Ну что Вы, Дитрий, в самом деле, не даёте даже
                > словоблудием поразвлекаться в пятницу-то.

                Ой, я не догадался. В субботу прочитал 😀

  • ZW

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

  • Андрей

    А если эта система не просто “коробка”, с “коробочными” процессами внутри, а система, позволяющая при всей своей неоднозначной простоте необходимую гибкость настройки для определенного Заказчика??
    И кроме того, в той самой коробке заложен опыт, функциональность и требования нескольких сотен клиентов по всему миру за не один десяток лет?

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

    • Дмитрий Исайченко

      Мне показалось, в первых двух абзацах сформулирован вопрос. К кому? В чем он заключается? Вы призываете “не клеймить коробки” или “не клеймить одну конкретную (понятно какую) коробку” или я не уловил Вашу мысль?

      • Андрей

        согласен, не совсем корректно получилось..
        Речь о том, что есть системы, в которых “можно все” и при этом “развязаны руки” для сколько угодно серьезных доработках. Это приводит к довольно неприятным вещам, например, к очень непростой поддержке системы.
        Есть системы, в чистом виде “из коробки”, в которых “шаг влево/вправо – расстрел”.

        Идеальным же случаем я вижу чтото среднее. Незачем оставлять в системе возможности залезать “куда не надо”, автоматизировать возможности, которые “никому не нужны” или “ни к чему хорошему не приведут”.

        • Татьяна Фомина

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

          • Андрей

            Нисколько не привязываюсь к какойто конкретной системе:). Есть ряд систем с такими же проблемами “одного известного тут всем продукта”.
            Пока я очень скептически отношусь к сложным и “всемогущим” системам, хотя, вполне возможно, что я еще не совсеми из них хорошо знаком.

            • Олег Скрынник

              Про сложные и всемогущие системы – согласен, это не меньшее зло, чем “коробка”.

              Наверное, не стоит уходить ни в одну из крайностей. Истина, как известно, где-то рядом 🙂

      • Николай

        Для меня вопрос Андрея очевиден – и он риторический))
        Есть ИС, которые удачно сочетают “гибкость настроек” с “жесткостью правил”… вот только пока что это ERP, WMS, HRP системы, но только не ITSM.
        И возможно для того, чтобы подобные “идеальные” продукты появились для ИТ нужно, чтобы ITSM было столько же лет, сколько GAAP…

    • Олег Скрынник

      “в той самой коробке заложен опыт, функциональность и требования нескольких сотен клиентов по всему миру за не один десяток лет”

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

      Теперь несколько вопросов, для примера.
      В том же ITIL нам красиво рассказывают про разные виды Service Desk – локальный, централизованный, и даже виртуальный. Все имеют право на существование, все встречаются на практике. Который из них в коробке? Очевидно, что и процессы, и инструмент должны учитывать эту специфику.

      Второй пример: управление инцидентами и управление запросами пользователей – это один процесс или два? Правильный ответ, на мой взгляд – зависит от решаемой задачи. Бывает и так, и так. А обобщённый опыт сотен клиентов нам что говорит? 🙂

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

      PS. Я думаю что коробки, конечно же, имеют право на существование. В небольшой компании, которая только озадачилась наведением порядка в своей поддержке, можно просто поставить ЛЮБОЙ софт учёта заявок, и уже станет лучше. Но этот этап быстро заканчивается 🙂

      • Павел Солопов

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

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

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

        • Олег Скрынник

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

          Более того, “коробка” в ряде случаев может означать “кривые процедуры, придуманные фиг знает кем из Голландии/США/Германии, которые к нашему случаю не имеют никакого отношения, а работать приходится именно по ним”.

      • Андрей

        “Вряд ли эти сотни клиентов за десятки лет были одинаковыми. Наверное, у каждого были свои особенности, а значит — свои специфические требования.”

        У всех этих сотен клиентов были и похожие, возможно даже в чем-то одинаковых требования. Разве нет?
        Можно заложить в “коробочную”функциональность как раз эти вещи, а всю остальную гибкость и дорабатываемый функционал реализовывать около всех остальных особенностей отдельного заказчика. Вот и получится что-то среднее между двумя “крайностями”.

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

  • Евгений Шилов

    Конечно, коробки в некоторых случаях это прекрасно, ибо быстро, иногда дешево, еще реже сердито. Но, когда поставщик ПО утверждает, что заложенные в его коробку процессы, единственные правильные и любой отступивший от них – “еретик”, есть повод задуматься о добросовестности такого поставщика, не прикрывает ли он этими заявлениями недостатки своего продукта.
    Мне не даст соврать Дима, в одном из проектов мы сравнивали для заказчика несколько хорошо нам всем известных продуктов автоматизации ITSM процессов (насколько хорошо они смогут автоматизировать уже существующие у заказчика процессы). В ходе сравнения приглашали представителей от производителей этих продуктов (некоторые пришли сами, некоторые прислали партнеров). И вот, в ходе демонстрации “супер-мега-гибкого” продукта представителям поставщика задается вопрос: “Отлично, возможности вашего продукта по работе с CMDB действительно впечатляют, но вот структура CMDB нам не подходит, т.к. процесс управления конфигурациями у нас уже работает и структура уже разработана, заточена под наши задачи и нас вполне устраивает. Сможем мы настроить Ваш продукт под нашу структуру?” Ответ поставщика был следующим: “Вы знаете, мы регулярно встречаемся вот с такими компаниями, которые думают, что самые умные, придумывают свои структуры CMDB, а потом менеджеры процессов волосы на голове рвут и возвращаются к нашей структуре.” И только после того как им был представлен менеджер процесса, очень даже с волосами, который объяснил, что он доволен своим процессом, представители стали уклончиво рассказывать, что конечно можно, но это столько мороки: там переделать, тут подтесать и т.д.
    Все это я к тому, что коробки хороши, но всегда должна быть возможность от нее отойти, взяв за основу, или вообще отказавшись от части коробки. А если коробка начинает навязывать вам решение тех задач, которые вам не нужны, так зачем за нее платить деньги?

  • Михаил

    Мда…. развели тут Holy Wars 🙂 Лично мое отношение к этому очень простое: главное – словить баланс 🙂 Для кого-то и коробки за глаза хватит, и он будет счастлив (чуть не написал “в браке” :-)) много-много лет. Для кого-то гибкость продукта является критичной и он не готов идти на компромисс. Кто-то будет мириться с какими-то ограничениями и т.д… Универсального лекарства нет. А вот “баланс” – шука тонкая и зависит от кучи факторов, в числе которых не последнюю роль играет и опыт консультантов… Так что, как говорил Фокс Малдер – “руль где-то рядом” Всем фанатам “типовухи” и “гибких средств” предлагаю взяться за руки пройти в сторону ближайшего пивного ларька. Я к вам присоединюсь 🙂

  • Алексей Юсов

    “Коробка” хороша и подходит на 100% только продавцу её самой как маркетинговый ход – “купите это – будет Вам счастье”. Для заказчика важно лишь эффективное (на самом деле, а не в буклетах и презентациях) решение его задач. Его бизнес такой, какой он есть, хороший или плохой. Другое дело, если заказчик сам или с помощью консультантов придёт к решению об изменении своих процессов “под коробку”. Вся проблема лишь в противостоянии интересов продавца и покупателя.

  • Лялеко Владимир

    По теме обсуждения оффтоп:

    Верного ответа ” что лучше?” быть не может.
    Выбор коробка \ платформа \ что-то “среднее” всегда зависит от конкретного заказчика и конкретных условий.

    Есть множество реальных примеров \ тендеров, когда техническо-политические правила игры ставили крест, как на коробочных решениях, так и на сложных платформах.

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

    По теме статьи:

    Считаю, что ITSM творческая профессия. В ней есть как стандартная методология, так и креативные идеи, нестандартные подходы. Роб Ингланд яркий тому пример 🙂

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

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

    Ответ на мой взгляд кроется в подготовке релиза \ версии процесса.

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

    Далее мы взрослеем, рождаем новые идеи на основе тех вещей, которые не досмотрели при первом релизе и на основе повышения уровня зрелости компании в целом.

    После анализа этих идей \ потребностей рождается новый релиз, потом ещё и ещё. По сути это бесконечный процесс.

    Так мы реализуем свой творческий потенциал в течение всей жизни, при этом, не отрываясь от реальности.

    Нам развязали руки, не хотелось бы теперь связывать себя добровольно 🙂

  • ZW

    Коробки – не коробки.
    У любой системы есть ограничения. Задача проектировщика/внедренца заметить эти ограничения на этапе проектирования, а не в процессе внедрения.

    PS. некоторые ограничения могут возникать из-за неправильно обращения с “инструментом”
    PPS. Вышеприведенное не отменяет варианта наличия таких ограничений, из-за которых проще поменять что-то на предприятии, чем в коробке. Или поменять коробку.

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

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

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