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

О пользе ценностей

И бизнес, и ИТ в своей работе выполняют множество различных видов деятельности. Часть действий связана с заранее известными событиями, поэтому их обработку можно выполнять при помощи заранее спроектированных процессов, разработанных процедур и протоколов взаимодействия. Однако, есть и другой тип событий – малопредсказуемые, требующие оценки и принятия решения по времени и месту их возникновения. Стандарты и своды знаний предлагают наборы процессов для известных или обычных событий, описывают процедуры их обработки. А как поступать в тех случаях, когда кому-либо требуется сделать выбор и принять решение, о котором не написано в книгах?

Консультант Марк Смолли отмечает в своей заметке, что поведение зависит от многих факторов: "кнут и пряник", "знания и навыки", "рабочая обстановка и имеющиеся ресурсы", "физическое и психическое состояние личности", "образ мышления и убеждения". Убеждения или жизненные ценности являются самыми глубокими и весомыми факторами, оказывающими влияние на поведение человека. В качестве примера Марк приводит Schuberg Philis, аутсорсинговую компанию из Нидерландов, в своё время принявшую решение об инвестициях именно в жизненные ценности. Девиз этой инновационой организации – "Каждый в нашей организации может заниматься чем угодно до тех пор, пока он соблюдает наши основополагающие принципы". Принципов двенадцать, и звучат они так:

  • любовь – человечное отношение к сотрудникам
  • лидерство – "мы все заодно"
  • выход из зоны комфорта – переосмысление возможностей
  • уязвимость – в ней подлинная сила
  • заказчики – привилегия быть им полезными
  • выравнивание сильных сторон – слабости не имеют значения
  • химия взаимоотношений – изменения в течение всей жизни
  • принципиально новая организация совместной работы – … в среде, где работают без руководителя
  • обещание 100% – все возможности мира
  • возможности мира – мы хотим быть его частью
  • технологии по экспоненте – мощь ИТ
  • обучение без страха – всё начинается с любопытства

Компания позволяет своим сотрудникам быть автономными, тщательно при этом отбирая в свой штат тех, кто соответствует её организационной культуре. В самой компании причиной ее успешности называют приверженность одному-единственному, но очень важному KPI – 100% удовлетворенности заказчика. Используя его в качестве главного ориентира, сотрудники интуитивно опираются на перечисленные жизненные ценности и принимают решения, которые кажутся верными в конкретной ситуации. Они свободны в принятии решений, получают удовольствие и удовлетворение от работы, выполняемой раз от раза все лучше и приносящей пользу.

Есть жизненные ценности, есть ценности компаний, которые, как в примере выше, приводят к успеху. А как обстоит дело с ценностями в других областях? Марк рассматривает Agile, IT Service Management (ITSM) и Business Information Management (BIM).

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

  • люди и их взаимодействие превыше процессов и инструментов
  • работающее ПО важнее исчерпывающей документации
  • сотрудничество с заказчиком приоритетнее обсуждения условий договора
  • активное участие в изменении вместо следования плану

ITSM. В очень похожем ключе в 2013 году, в Нэшвилле, на Конгрессе сервис-менеджмента были сформированы ценности, специфичные для ITSM:

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

BIM. Фонд ASL BiSL (Application Services Library, Business Information Services Library) представляет собой некоммерческую организацию, разработавшую такой свод знаний как BiSL. В отличие от ITIL, рассматривающего деятельность поставщика ИТ-услуг, BiSL фокусируется на другой "стороне" – заказчике ИТ-услуг и вопросах его "правильного" взаимодействия с ИТ. Ценности BIM есть и также сформулированы, но ещё широко не обсуждались и не утверждены. Это событие запланировано на декабрь, когда состоится ежегодная конференция, организуемая Фондом. Предварительно ценности BIM сейчас звучат так:

  • фокус на выгодах для бизнеса, а не на технологиях
  • фокус на информации, а не на услугах
  • обработка разнородных требований, а не поставка стандартных ИТ-решений
  • предпочтение работающему уже сегодня решению, а не отличному, но завтра
  • надёжный партнёр бизнеса, а не приёмщик запросов

После принятия их сообществом, говорит Марк, будет опубликован манифест BIM. По всей видимости, от этого будет зависеть и его успех.

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

  • Андрей

    Я что-то не понял – они всё таки добрались до "шедевров" коммунистической агитации и пропоганда времен СССР?

    Ну ведь "кодекс строителя коммунима" в чистом виде. Все доджны быть честными, беззаветно служить целям марксизма-ленинизам, тьфу черт, нет – целям бизнеса и не жалеть живота своего ради всеобщего счастья в рамках компании-заказчика.:)))

    А я думал, что процессы – основа технологии, а она, в свою очередь, есть основа ГАРАНТИРОВАННОГО достижения требуемого уровня качества и коичества выпускаемой продукции, и это важно. Ан нет, оказывается Левша лучше чем станок с ЧПУ.:)))

    • Владимир Калёнов

      Скорее здесь банальное признание факта, что в текущих реалиях "процесс" не равен "цепочке создания ценности". Т.е. станок ЧПУ куда лучше Левши, но если у вас 500 станков с ЧПУ, то вам важнее иметь команду настройщиков, которые быстро перенастроят станки под потребности заказчиков. В противовес заваливанию складов валенками летом 🙂 Кстати IT4IT http://www.opengroup.org/IT4IT/overview как раз этот факт и декларирует.
      А принципы Agile можно и менее добрыми словами сказать (если вспомнить, как этот манифест вообще появился):
      – позициция "Это не моя зона ответственности, мне все равно, что мой процесс мешает твоему" приводит к отсутствию результата.
      – пока вы пишете документацию ради документации у ваших заказчиков меняются требования

      – вы все равно что-то не учтете в договоре, поэтому начните договариваться сразу

      – если вы не помогаете заказчику справиться с изменением, он скоро перестанет быть вашим заказчиком

      • Андрей

        ….. если у вас 500 станков с ЧПУ, то вам важнее иметь команду настройщиков.

        Мне кажется, что несколько иначе. КОГДА у вас УЖЕ есть станки с ЧПУ, то вам нужна команда, которая будет оперативно и качественно …. опаньки, а что же они будут быстро и каченственно делать? они будут выполнять ПРОЦЕСС настройки. И если я хочу, чтобы процесс ВСЕГДА выполнялся быстро  в требуемые сроки и лучше всех с заданным качеством, я постараюсь ФОРМАЛИЗОВАТЬ и АВТОМАТИЗИРОВАТЬ этот процесс, чтобы он у меня от Левши (его настроения, самочуствия, отношений в семье и т.д.) не зависел. В примере с ЧПУ это теперь делается в системах проектирования CAD. Они сами разносят процесс изготовления по типам станков и готовят конфигурационные файлы.

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

        • Владимир Калёнов

          Ну в этом примере я конечно соглашусь. Единственное, здесь есть вопрос в специфике бизнеса, ведь цепочка не с настройщиков начинается и если у меня 2 вида продукции в год, то я вкладываюсь в формализацию и автоматизацию, а если малые заказы и много, то мне может быть выгоднее трех Левшей-настройщиков взаимозаменяемых найти, и качество процесса контролем на выходе измерять. Да и на коленке хорошо уметь работать, "хороша ложка к обеду". Главное в крайности не впадать.
          А про щустрый подход, здесь такая же путаница как c ITSM и ITIL. Есть принципы Agile, им, например, сервисный подход соответсвтвует, есть методики которые многие как ITIL "внедряют". Причем методики, что TOC, что SCRUM, что парное програмирование прекрасно и в нещустрых компаниях работают (ибо придуманы задолго до манифеста).

          Чем выше стоимость стоимость ошибки заказчика при формировании потребности, тем более шустрыми должны становятся процессы. http://www.slideshare.net/VladimirKalenov/ss-55417688

          • Андрей

            Я не против шустрости как таковой. Я против средств и методов, предлагаемых для её достижения. Я против моментальной реализации хотелок закзачика без анализа и нормальной формализации. Но я ЗА использование методов и технологий, позволяющих значительно ускорить процессы формализации и анализа. Я за использование, на пример, CASE средств в разработке (это направление вообще забыли сегодня). Я за использование средств автоматизации релиза. Мне же сторонники шустрости говорят – это слишком дорого, мы лучше избавим сотрудников от необходимости "лишних рутинных операций" и за счет этого повысим скорость. Под лишними и рутинными при этом понимаются даже такие вещи, как документирование выполненных операций. 

            • Владимир Калёнов

              Ну, это какие-то "неправильные пчёлы" 🙂 Такой подход в среде разработки называется "MVP из кизяка и палок". В таких ситуациях можно напомнить сторонникам об истории Agile: манифест писали опытные специалисты, которые умели и работали очень стандартизированно, такие очень самоорганизованные чуваки. Там так и написано: "…не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева".

              Кстати, в классике команду от заказчика обязан отделять Product Owner. Есть очень хорошее видео по этому поводу: http://www.youtube.com/watch?v=loVd5MTCBWI 


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM