Бизнес-процессы: the good, the bad and the ugly

    В большой и даже не очень большой компании никак без процессов. Консалтинговое подразделение Hewlett Packard Enterprise Software занимается выстраиванием процессов в ИТ-подразделениях своих заказчиков. ITSM/ITIL, управление проектами, управление разработкой и DevOps – все эти слова. В рамках почти каждого проекта так или иначе мы проектируем и рисуем процессы.

    В данной заметке мы не будем говорить о теории, поговорим больше о практике с учётом того опыта, который накопился в российском HP, теперь уже в HPE. Чтобы говорить не отвлечённо, возьмём предметную область управления ИТ-услугами – ITSM, и говоря о процессах, будем иметь в виду процессы ITIL, к примеру. На абсолютную правоту не претендуем, будем рады обсудить данную тему.

    Зачем нужны процессы


    Мы считаем, что процессы нужны, чтобы люди в организации одинаково понимали, что и как они должны делать. Ещё можно говорить «чтобы структурировать деятельность организации» и много других слов.

    Здесь важно соблюдать разумный баланс между «структурированием» и практическим использованием людьми в работе. Проектирование (выстраивание) процесса – достаточно трудоёмкая задача, поэтому она должна иметь практический результат. У процессных документов должна быть достаточно широкая аудитория. В идеале – люди должны смотреть непосредственно в процессы и понимать, что и в каком порядке они должны делать в той или иной ситуации.

    В ряде заказчиков мы наблюдаем картину, когда процессы по ряду причин (о них – чуть ниже) становятся уделом узкого круга профильных процессных специалистов. Это как раз тот случай, когда «структурирование» (околонаучная задача) преобладает над практическим использованием. А если процесс не является «настольной книгой» людей, которые в рамках этого процесса работают, то пропадает или резко уменьшается поток обратной связи от исполнителей, которые видят, что процесс нуждается в изменении (совершенствовании).

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

    Процессы для людей


    Какими же должны быть описания бизнес-процессов, чтобы широкая аудитория могла получать от них пользу? – Достаточно простыми и практичными. Форма не должна преобладать над содержанием. Документ должен содержать информацию, необходимую и достаточную исполнителям процесса для его, собственно, исполнения.

    В описании процесса есть процессные диаграммы. Их можно рисовать по-разному, в разных нотациях и с разной степенью детализации. Сравним два варианта (это не один и тот же процесс, мы про нотации сейчас поговорим)


    Слева процесс в нотации swimlane (плавательный бассейн с «дорожками» для процессных ролей). Справа – в нотации EPC. У каждого варианта есть свои достоинства и недостатки. Вариант слева – менее формальный, позволяет некоторые вольности в отражении действий в рамках процесса. У варианта справа гораздо более отточенная семантика, но эта «форма» требует дополнительных трудозатрат на её прорисовку. Да, повышается формализация процесса и исключаются возможные ошибки при «структурировании» деятельности. Но диаграмма становится менее читаемой. Разумеется, есть варианты и посередине.

    Мы в HPE Software Services – убеждённые сторонники первого варианта, потому как его понимание не требует практически никаких специальных навыков и знаний, всё более или менее очевидно. Это, в том числе, обеспечивает возможность понимания процесса широкой целевой аудиторией. Содержание преобладает над формой, и это, на наш взгляд, неплохо.

    Целостность и непротиворечивость


    Ещё одна задача – контроль процессного ландшафта в целом. Чтобы все процессы были взаимно согласованы и несильно отставали в своём развитии друг от друга. На каком-то мероприятии приводилась аналогия с домом из кирпича. Какую стену дома строить сначала, а какую потом? – Все сразу. Нельзя, чтобы одна стена была сильно выше другой. Сначала заводим углы, а потом постепенно поднимаем все стены.

    Большая формализация требует больших усилий на поддержание консистентности процессных моделей, взаимное соответствие интерфейсов между процессами, единство терминологии, подходов к формированию KPI, ролевой модели и т.д.

    Здесь нам тоже кажется, что лучше пожертвовать формой и детализацией, но спроектировать и прорисовать больше процессов. То есть охват важнее детальности.

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

    Выскажу крамольную мысль, но я правда так думаю – лучше подняться в небо на достаточно простом двухместном самолётике, чем построить красивый и большой авиалайнер и не быть уверенным, взлетит эта штука или нет.

    Результат рисования процессов важнее и ценнее процесса рисования процессов, если угодно.
    Hewlett Packard Enterprise
    90.76
    Company
    Share post

    Comments 5

      +4
      > В данной заметке мы не будем говорить о теории, поговорим больше о практике
      А где практика? Одна теория, которая сводится к "Результат рисования процессов важнее и ценнее процесса рисования процессов".

      > А если процесс не является «настольной книгой» людей ...
      Вот и рассказали бы как сделать так, чтобы процесс стал «настольной книгой». В большинстве случаев, даже процессы соответствующие всем критериям хорошести, перечисленным в статье, остаются уделом узкого круга лиц. Потому что начальнику цеха не важно, что там нарисовали умники из заводоуправления, которые в цеху почти ни когда не бывали. Он и без процессов разрулит любую ситуацию.
      А для ITIL уже все программы написаны, зачем ещё нужны процессы?
        0
        Спасибо за комментарий. Найду время и постараюсь написать с примерами, как сделать процесс «настольной книгой». Тема непростая, но очень интересная.

        На высоком уровне в ITIL процессы, безусловно, описаны. А дальше — дьявол в деталях. Во многих областях есть лучшие практики (а иногда даже законодательные нормы), и есть коробочные продукты, которые им соответствуют, но всё же зачем-то их ещё нужно тюнить и настраивать. Бухгалтерия и расчёт зарплаты, например, — куда более регламентированные вещи, а всё же 1С-ников в стране пруд пруди. Казалось бы, всё написано в законодательных и подзаконных актах, а всё же.

        Так что в части управления эксплуатацией тоже есть тонкости, о которых надо думать. Межрегиональное взаимодействие, круглосуточная территориально-распределённая поддержка, управление изменениями и оценка их влияния — очень много разных вещей, которые мало где описаны и сделаны хорошо. Так что, погрузившись глубоко в тему, можно найти много точек для совершенствования.
        0
        Заметка как заметка.
          0
          «В идеале – люди должны смотреть непосредственно в процессы и понимать, что и в каком порядке они должны делать в той или иной ситуации.»

          Да ну. В идеале — имплементировать ваш бизнес-процесс как стэйт-машину в каком-нибудь конструкторе типа JIRA. Это называется «Автоматизация деятельности на предприятии». А потом можно и следить и узкие места выявлять с помощью канбан-доски и т.п. Процесс как диаграмма — это прошлый век.
            0
            Так и я о том, коллега. Люди должны смотреть в процесс, и лучше — сразу в системе автоматизации, безусловно. И вкладывать ресурсы нужно не в рисование процессов в сложночитаемых нотациях, а в то, чтобы организация побыстрее начинала получать пользу от процессов. А это возможно, если есть правильное сочетание и взаимодействие трёх компонентов: процессы+люди+технологии. О чём и вы пишете.

            Так что полностью с вами согласен. Ну разве что кроме JIRA. Всё же я сотрудник Hewlett Packard Enterprise :)

          Only users with full accounts can post comments. Log in, please.