Эта лекция посвящена новшеству ITIL - системе создания ценности сервиса, которая уже кратко упоминалась в лекции 3.
Система создания ценности сервиса (Service value system, SVS) - модель, описывающая как работают все компоненты и активы организации для обеспечения создания ценности[1].
Структура SVS показана на рисунке 4.1.
По сути SVS является самой высокоуровневой моделью новой версии ITIL. Основными входами в SVS являются возможности и спрос. Возможности подразумевают различные варианты повышения ценности для заинтересованных сторон, а спрос отражает потребность или желание иметь продукты или сервисы организации со стороны внешних и внутренних потребителей. Выходом модели SVS является ценность, которая, если вспомнить предыдущие лекции, выражается в полезности, пользе и важности чего-либо.
SVS содержит 5 основных компонентов:
SVS описывает то, как компоненты и деятельности в рамках организации работают вместе как единая система для создания ценности.
В ITIL4 много упоминаний так называемых организационных силосов (organization silos). Организационный силос возникает, когда отделы и другие части организации работают изолированно друг от друга, не обмениваются информацией, целями, инструментами, процессами и т.п. Силосы мешают развитию организации, снижают вовлеченность сотрудников, препятствуют быстрым изменениям, которые необходимы в современном мире. Понятие силоса применимо и к практикам, если они реализуются в изоляции друг от друга. Все практики должны быть связаны друг с другом, чтобы этого избежать. Необходимо четкое понимание, в какой момент рабочего процесса должен происходить обмен информацией между практиками. Архитектура SVS благодаря своей гибкости и тому, что она не навязывает определенную последовательность действий (как это было в версии ITIL3), препятствует возникновению силосов. Несмотря на то, что в ITIL 4 есть примеры того, как можно построить потоки создания ценности, они не являются универсальными или обязательными. Универсальна фактически только сама модель SVS и ее компоненты, а то, как именно будет формироваться ценность, индивидуально для каждой организации. Такая архитектура позволяет SVS поддерживать различные подходы - как традиционные, так и относительно новые (например, DevOps и Agile).
Организационная гибкость и организационная устойчивость
Для того чтобы быть успешной, любая организация должна обладать организационной гибкостью для поддержки внутренних изменений и одновременно организационной устойчивостью, чтобы противостоять и даже процветать в изменяющихся внешних условиях. При этом любая организация является частью большей экосистемы организаций, каждая из которых предоставляет, координирует и потребляет товары и сервисы.
Организационная гибкость - способность организации быстро, гибко и решительно адаптироваться к внутренним изменениям. Внутренние изменения могут включать в себя изменения организационной структуры, слияния и поглощения, новые технологии и т.п.
Организационная устойчивость - способность организации предвидеть, подготавливаться, реагировать и адаптироваться к изменениям во внешнем окружении. Внешнее влияние может быть политическим, экономическим, социальным, технологическим, правовым и экологическим[1]. Такой устойчивости невозможно достигнуть без понимания целей и приоритетов организации. SVS поддерживает достижение организационной гибкости и устойчивости за счет задания общего направления, ориентированного на ценность.
Возможность, спрос и ценность
Как уже было сказано выше, возможность и спрос запускают активности в рамках SVS и это приводит к созданию ценности. Возможность и спрос всегда есть, но организация автоматически не использует все возможности или не удовлетворяет любой спрос.
Возможность представляет различные варианты повышения ценности для заинтересованных сторон или улучшения организации. Спроса, соответствующего возможности, может еще не быть, но возможность сама по себе может запустить работу системы SVS.
Спрос представляет собой потребность или желание иметь продукты или сервисы организации со стороны внешних и внутренних потребителей.
Принцип руководства - это рекомендация, которая поможет руководить организацией в любых обстоятельствах вне зависимости от окружающих условий, изменения цели, стратегии, структуры управления и т.п.
В таблице 4.1 приведен обзор принципов руководства ITIL4[1]. Всего их 7.
| Принцип управления | Описание |
|---|---|
| Фокус на ценность | Все, что делает организация, должно прямо или косвенно отражаться на ценности заинтересованных сторон.
Фокус на ценность охватывает различные аспекты, в том числе опыт пользователей и заказчиков |
| Начинай там, где ты есть | Не стоит начинать делать всё с нуля и строить что-то новое без оценки того, что уже доступно для использования. Имеющиеся ресурсы (сервисы, процессы, программы, проекты и люди) скорее всего можно использовать для достижения желаемого результата.
Текущее состояние должно быть досконально исследовано и понятно. |
| Прогрессируй итеративно с использованием обратной связи | Не пытайтесь сделать всё сразу. Большие проекты должны выполняться итеративно.
Работу необходимо разбивать на более мелкие части, которыми легче управлять. Это позволит лучше сфокусировать внимание и выполнить каждую из частей своевременно. Обратная связь до, во время и после каждой итерации позволит убедиться в том, что работа идет в правильном направлении, даже если обстоятельства меняются |
| Сотрудничай и способствуй прозрачности | Совместная работа над чем-то дает результаты, которые больше соответствуют целям, а также увеличивает вероятность долгосрочного успеха.
Достижение целей требует информации, понимания и доверия. Вся работа и ее последствия должны быть прозрачны, а обмен информацией - максимальным. |
| Думай и работай целостно | Ни один сервис или элемент, который его поддерживает, не работает в изоляции. Организация должна использовать целостный подход к сервису, иначе пострадают результаты, которых ждут различные участники сервисных отношений. |
| Держи всё простым и практичным | Если процесс, сервис, действие или метрика не может обеспечить ценность или произвести полезный результат, устраните этот элемент. В процессе или процедуре используйте минимальное количество шагов, необходимых для достижения цели (целей). Мышление должно быть всегда ориентировано на результат, чтобы вырабатывать практичные решения, обеспечивающие его. |
| Оптимизируй и автоматизируй | Ресурсы всех типов (особенно кадровые) должны использоваться с максимальной отдачей. Устраните всё, что приводит к ненужным затратам, и используйте технологии там, где это возможно. Вмешательство человека должно быть только там, где оно действительно необходимо. |
Аналогичные принципы отражены во многих других методиках и стандартах (Lean, Agile, DevOps и COBIT). Они универсальны и позволяют организациям использовать различные методы в рамках сервис-менеджмента.
ITIL, Agile и DevOps
Agile-методы, или как их еще называют гибкие методы (от англ. agile - гибкий), применительно к области разработки программного обеспечения, фокусируются на предоставлении инкрементных изменений ПО с учетом изменяющихся требований пользователей. ITIL4 предупреждает, что при таком подходе может потеряться целостное понимание конечного продукта. Помимо этого инициативы по улучшению и обучение могут иметь узкую направленность (например, приоритезация требований пользователей или упрощение процедур разработки, развертывания и тестирования программного обеспечения). Эти инициативы могут принести значимые результаты, но одновременно несут в себе риски потери контроля над остальными составляющими сервис-менеджмента. ITIL может обеспечить организации, занимающиеся разработкой программного обеспечения, более широким видением и языком взаимодействия с другими командами сервис-менеджмента.
Применение Agile без ITIL может в итоге привести к большим затратам. В свою очередь применение ITIL без Agile может привести к созданию бюрократичных, медленных и негибких структур и практик.
Когда Agile и ITIL применяются вместе, разработка ПО и сервис-менеджмент развиваются вместе, используют общую терминологию и поддерживают совместное создание ценности организацией и другими заинтересованными сторонами сервисных отношений.
DevOps (от англ. development и operations) - методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов, занимающихся разработкой, и специалистов, занимающихся сопровождением. Аспекты культуры DevOps могут и должны быть использованы во всех потоках создания ценности, чтобы различные группы сотрудников в организации действовали согласованно.
Можно сказать, что DevOps объединил в себе методы разработки ПО (Agile), эффективное управление и целостный подход к совместному созданию ценности (ITIL) и стремление к постоянному изучению и улучшению механизмов создания ценности (Lean).
Вся деятельность, осуществляемая организацией, должна отражаться косвенно или прямо на ценности, которую в итоге получает организация, ее заказчики или другие заинтересованные стороны сервисных отношений.
Чтобы реализовать первый принцип руководства, предлагаемый ITIL4, сначала организация должна понять - кто является потребителем ее сервисов.
Затем - что действительно представляет ценность для потребителей. Мы уже упоминали о том, что ценность - субъективное понятие и чтобы она действительно была, поставщик сервисов должен знать ответы на следующие вопросы:
Ценность с точки зрения потребителя:
Важную роль играет также потребительский опыт (customer experience - СХ). CX складывается из совокупности взаимодействий потребителя с организацией и ее продуктами. Этот опыт определяет, как потребитель относится к организации, ее продуктам и сервисам. При управлении CX следует помнить, что он может быть как субъективным, так и объективным. Например, Вы заказали пиццу в ресторане и получили ее горячей, в назначенное время. Этот опыт вероятнее всего будет положительным, так как такие параметры как сроки доставки, качество, согласованная цена являются объективными. В то же время Вам может не понравится дизайн приложения, через которое был осуществлен заказ пиццы. В этом случае это субъективная оценка, так как кому-то этот дизайн может понравится.
Чтобы применять принцип «Фокус на ценности» успешно, необходимо следовать следующим советам[1]:
Этот принцип руководства говорит о следующем: в попытках улучшения своей деятельности и создания новых продуктов/сервисов, не стоит принимать кардинальные решения и сразу отказываться от текущих технологий, процессов, процедур и т.п. Это приводит к лишним потерям времени и затратам. Гораздо эффективнее комплексно оценить свое текущее состояние и максимально использовать имеющиеся ресурсы. Кратко можно сказать так: «Не начинайте всё сначала, не рассмотрев то, что уже есть и доступно для использования».
Помимо этого сам факт наблюдения может оказать влияние на результаты. Например, если сотрудник Service Desk знает, что за ним наблюдают, он может брать легкие заявки в работу и делать их быстро. В итоге по отчету получится, что можно сделать 100 заявок в день, хотя на самом деле бывают сложные заявки, требующие несколько часов на решение, и средняя статистика выполнения будет 50 заявок в день, а не 100.
Поэтому при оценке текущего состояния важно использовать как измерения, так и непосредственное наблюдение за оцениваемым объектом.
Для применения принципа «Начинай там, где ты есть» необходимо следовать следующим советам[1]:
Данный принцип говорит о том, что любую работу проще и эффективнее сделать по частям. Отдельные части большой задачи лучше поддаются управлению и измерению. Простыми словами итерационное развитие - это постепенное развитие с помощью последовательных или параллельных итераций на улучшение. Каждой итерацией необходимо управлять, в том числе контролировать временные рамки и результат, который она приносит. При этом в рамках отдельных итераций необходимо сохранить ориентированность на ценность.
В результате изменения обстоятельств или приоритетов может возникнуть необходимость в корректировке хода работ или их отмене. Для быстрой адаптации необходимо иметь обратную связь до, во время и после реализации каждой итераций по улучшению. Информация, полученная от обратной связи, будет использована в качестве входа для следующей итерации (петля обратной связи).
Хорошо налаженная обратная связь помогает проанализировать следующие аспекты:
Результаты обратной связи могут быть использованы для оценки рисков, поиска проблем и возможностей для улучшений.
Работа в соответствии с принципом «Прогрессируй итеративно с использованием обратной связи» обеспечивает:
Для успешного применения данного принципа необходимо следовать следующим советам[1]:
Привлечение к реализации какой-либо инициативы подходящих людей на соответствующие роли приводит к общей согласованности действий, увеличению релевантности управленческих решений (за счет качественной информации для принятия решений) и долгосрочному успеху.
Взаимодействие и сотрудничество всегда лучше изолированной работы, которая может привести к возникновению организационных силосов (которые уже упоминались ранее). Силосы возникают не только из-за поведения отдельных людей или команд, но и из-за структурных особенностей: когда процессы, документация, функции и процедуры разработаны для отдельных частей организации.
Необходимость сотрудничества стала ключевым фактором развития методологии DevOps. Следует отметить, что ни одна из существующих и популярных методологий не сможет работать без эффективного сотрудничества. Обмен информацией, понимание и доверие являются необходимыми составляющими такого сотрудничества. Необходимо стремиться к максимальной прозрачности - чем больше участников понимают то, что происходит, тем больше вероятность получения квалифицированной и своевременной помощи.
Для поиска тех, с кем можно сотрудничать, организация может обратиться к группам заинтересованных сторон, участвующих в сервисных отношениях: это сотрудники самой организации, ее потребители, поставщики, партнеры и т.д. Наиболее очевидной и, пожалуй, значимой группой являются потребители. Очень важно получать от них постоянную обратную связь и развивать отношения сотрудничества, а не простого «заказчик-поставщик».
Другие примеры сотрудничества заинтересованных сторон:
Уровень и способы сотрудничества с заинтересованными сторонами могут быть различными в зависимости от практики сложившихся отношений: обезличенный опрос на сайте, различные чек-листы или же более тесное взаимодействие через переговоры и инструменты коллективной работы.
Второй составляющей данного руководящего принципа является прозрачность. Ее недостаток или отсутствие приводит к тому, заинтересованные стороны начинают принимать неверные решения и неправильно оценивать ситуацию.
Например, потребитель попросил доработку программного обеспечения, при этом работа по реализации непрозрачна, через некоторое время у него может сложиться впечатление, что его требование ничего не значит для поставщика сервисов. Некорректная оценка возможна и внутренними командами. Внутренние команды расставляют приоритеты между задачами по операционной поддержке и по улучшению (развитию). Если со стороны руководства организации важность задач по развитию не транслируется, они получат низкий приоритет.
Для успешного применения данного принципа необходимо следовать следующим советам[1]:
Деятельность организации должна быть сосредоточена на создании ценности. При этом ни один из элементов, участвующих в системе создания ценности, не является изолированным - сервисы, процессы, практики, отделы, поставщики и т.п. связаны друг с другом. Отсюда возникает необходимость управлять ими комплексно. В сложной системе, которой является любая организация, изменение одного элемента может повлиять на множество других. Целостный подход включает в себя понимание взаимозависимостей различных элементов и того, как они работают вместе, что в свою очередь позволяет оценить и спланировать влияние любых изменений.
Для успешного применения данного принципа необходимо следовать следующим советам:
Принцип заключается в том, чтобы при решении любой задачи получить желаемый результат за минимальное количество шагов. При этом если процесс, сервис, действие или метрика не могут дать ожидаемый результат - от них необходимо отказаться.
Несмотря на кажущуюся очевидность данного принципа, на практике о нем часто забывают, отдавая предпочтения сложным решениям, которые при этом не улучшают результат и не минимизируют затраты организации.
Попытки найти решение, которое будет учитывать все исключения, часто приводят к излишнему усложнению. При создании процесса или сервиса проектировщики должны учитывать исключения, но необходимо понимать, что невозможно учесть их все. Иногда для исключений эффективнее будет разработать организационные правила.
При анализе практики, процесса, сервиса или любого другого объекта улучшения следует оценивать его вклад в создание ценности.
При проектировании или улучшении какого-то компонента сервис-менеджмента лучше всего начинать с чего-то простого, а затем постепенно наращивать сложность: добавлять контрольные процедуры, метрики и активности при возникновении соответствующей необходимости.
Понимание того, как каждый компонент участвует в потоке создания ценности, является критически важным для поддержания простоты сервис-менеджмента. Например, какой-то шаг в процессе может восприниматься персоналом операционной поддержки лишним, однако фактически он исполняется для выполнения требований регуляторов. Именно поэтому важно достичь понимания целостной картины формирования ценности от каждого участника.
При проектировании, управлении и эксплуатации практик необходимо устранять противоречия в целях. Сервисы должны собирать данные, которые действительно необходимы для принятия решений, а сам процесс сбора данных должен быть максимально простым и автоматизированным.
Для успешного применения данного принципа необходимо следовать следующим советам[1]:
Любая организация стремится к тому, чтобы максимально эффективно использовать технологические и людские ресурсы. Технологии можно использовать для регулярных и однотипных задач, тем самым высвобождая людей для задач, требующих участия человека. Тем не менее, не стоит совсем исключать возможность вмешательства человека в автоматизированные процедуры, так как это сильно увеличивает стоимость автоматизации и снижает устойчивость организации.
Прежде чем автоматизировать практику или сервис, необходимо сначала провести оптимизацию. При этом организация может использовать любую практику и методику: постоянное улучшение из ITIL, Lean, DevOps, Kanban и т.д. Вне зависимости от выбранной методики верхнеуровневые шаги должны быть следующими:
Автоматизация стандартных и повторяющихся задач позволяет сохранить затраты организации на прежнем уровне, уменьшить вероятность человеческих ошибок и избавить сотрудников от выполнения монотонных задач.
Для успешного применения данного принципа необходимо следовать следующим советам:
При применении этого принципа используйте другие принципы управления:
Мы рассмотрели семь принципов руководства, предлагаемых ITIL4. Важно понимать, что все они взаимодействуют и зависят друг от друга. Например, если организация использует принцип итерационного развития с обратной связью, она должна также использовать принцип целостного подхода, чтобы каждая итерация улучшения охватывала все необходимые элементы.
При возникновении ситуации, требующей принятия решения, необходимо обратиться к рассмотренным принципам и понять, какие из них наиболее уместны в конкретном случае.
Следующей составляющей Системы Создания Ценности (SVS), которую необходимо рассмотреть, является Руководство.
У каждой организации есть Руководство - человек или группа людей, которая несет ответственность на самом высоком уровне за результаты работы и соответствие требованиям.
Руководство осуществляется выполнением следующих видов деятельности[1]:
Руководство регулярно оценивает организацию, портфель сервисов, стратегию, взаимоотношения с партнерами и поставщиками и т.п., так как потребности заинтересованных сторон и окружающие обстоятельства постоянно меняются.
Руководство отвечает за формирование стратегии и политик организации и их реализацию. Стратегия в свою очередь определяет будущее развитие в виде приоритетов деятельности, инвестиций и т.п. Политики устанавливают требования к поведению в рамках всей организации и, там, где это уместно, у поставщиков, партнеров и других заинтересованных сторон.
Руководство постоянно отслеживает работу сервисов, процедур и практик на предмет соответствия выбранному направлению и политикам организации.
Руководство контролирует все сферы деятельности организации, в том числе сервис-менеджмент. Так как модель SVS может быть применена как к целой организации, так и к отдельному подразделению и даже продукту, при делегировании некоторых полномочий управления важно сохранить целостный подход, соответствующий целям и приоритетам организации.
Руководство организации может применять принципы, предлагаемые ITIL или разработать свои. Важно, чтобы принципы принятия решений были понятны и транслировались в рамках организации.
Необходимо убедиться что:
Следует отметить, что в тексте ITIL4 вместо термина «Руководство» используется «Руководящий орган» (governing body).
Постоянное улучшение также является компонентом SVS. Подходы постоянного улучшения применяются как к SVS в целом, так и к отдельным практикам, процессам, процедурам, продуктам, сервисам и сервисным компонентам и т.п. Если обобщить, то постоянное улучшение должно быть в отношении каждого компонента сервисных отношений. Каждый человек, участвующий в сервисных отношениях, должен понимать идею постоянного улучшения и искать возможности для улучшений в своей повседневной практике. Для достижения этого обязательными условиями являются поддержка постоянного улучшения со стороны руководства и трансляция соответствующих идей через корпоративную культуру и другие инструменты.
Подход постоянного улучшения не новинка ITIL4. Он присутствовал и в версии ITIL3. Сама идея постоянного улучшения пришла из цикла Деминга, более известного как PDCA ("Plan-Do-Check-Act"). PDCA представляет собой циклически повторяющийся процесс управления.
Цикл включает в себя 4 этапа (рис. 4.2):
ITIL4 поддерживает постоянное улучшение на всех уровнях и SVS включает в себя:
Рассмотрим высокоуровневую модель постоянного улучшения (Рисунок 4.3).
Когда и как ее можно использовать? Модель может помочь организации применять структурированный подход к постоянному улучшению и фокусироваться на ценности для потребителя. Модель предлагает итеративный подход к любой инициативе по совершенствованию, при котором итоговый результат достигается за счет последовательности дискретных шагов, каждый из которых имеет отдельную цель. При этом не обязательно выполнять все шаги модели или выполнять их именно в указанной последовательности - всегда нужно оценивать конкретную ситуацию, окружение, инициативу по улучшению и объект улучшения. Данная модель может задать некий вектор и подсказать правильные вопросы, о которых не стоит забывать при реализации улучшений.
Рассмотрим конкретные шаги в рамках этой модели.
Каково видение? Каждая инициатива по улучшению должна соответствовать целям, задачам организации и ее стратегии. Поэтому на первом шаге необходимо определить видение конкретной инициативы - ее высокоуровневое представление. Этот шаг помогает понять, какой вклад вносит конкретная инициатива в общее развитие организации, в чем ее ценность для бизнеса. В рамках этого шага отвечают на вопрос: «Зачем нужно данное улучшение в контексте бизнеса организации». Без его реализации вся деятельность по улучшению может сфокусироваться вокруг объектов, которые не приносят значимой ценности организации.
Где мы сейчас? На данном шаге оценивается текущее состояние, чтобы понять уровень требуемых организационных и других изменений. При этом необходимо использовать объективные измерения там, где это возможно. Без этого шага не будет зафиксировано начальное состояние, соответственно, трудно будет впоследствии оценить эффективность улучшения.
Где мы хотим быть? Состояние, в котором мы хотим оказаться в результате реализации улучшения. Оценивается разрыв между начальным и желаемым состоянием и шаги, которые необходимо предпринять, чтобы в нем оказаться. Возможности по улучшению могут быт приоритизированы на основе анализа разрывов, цели улучшения установлены вместе с критическими факторами успеха и ключевыми показателями эффективности.
Критический фактор успеха (critical success factors или CSF) - необходимое предварительное условие для достижения намеченных результатов.
Ключевой показатель эффективности (key performance indicators или KPI) - важный показатель, используемый для оценки успеха в достижении цели.
KPI используются для измерения реализации ключевых факторов успеха. Только важнейшие из всех измеримых метрик определяются как ключевые показатели эффективности и используются для отчётности и управления практикой, сервисом или
деятельностью.
Цели, CSF и KPI должны устанавливаться по принципу SMART, то есть быть конкретными (specific), измеримыми (measurable), достижимыми (achievable), согласованными (relevant,), ограниченными во времени (time). SMART позволяет перейти от абстракции к конкретике. Например, цель - сделать бизнес более прибыльным. Критический фактор успеха - повышение продаж. KPI - показатель объема продаж должен вырасти на 40% в течение года.
Без действий в рамках этого шага целевое состояние может быть непонятно ключевым заинтересованным сторонам, соответственно инициатива по улучшению не будет иметь поддержки.
Как мы достигнем желаемого состояния? После определения начальной и конечной точки, необходимо сформировать маршрут - план того, как желаемое будет достигнуто. Следует отметить, что на этом шаге не всегда есть определенность в отношении конкретных шагов, которые необходимо предпринять. Например, целью является повышение продаж. Но какие именно меры приведут к этому (реклама, снижение цены, повышение качества товара и т.п.) - неясно. Поэтому в рамках этого шага иногда требуется проработать различные варианты и выбрать те, которые имеют больший потенциал.
При этом ITIL рекомендует разрабатывать план в виде отдельных итераций, которыми легче управлять и отслеживать прогресс в достижении результата. То есть даже если известно, что именно нужно делать для реализации улучшения, лучше разбить деятельность на несколько более мелких шагов.
Действие. На данном шаге осуществляется реализация выбранного плана. Могут применяться как традиционный водопадный подход, так и Agile-подходы с итерациями, экспериментами, изменением условий и возвращением на предыдущие шаги. Ключевыми практиками данного шага является управление организационными изменениями, измерение и отчетность, управление рисками и постоянное улучшение.
Мы достигли того, чего хотели? На данном шаге происходит подтверждение достижения желаемого результата.
Как мы удержим результат? На предыдущем шаге был осуществлен контроль того, что желаемый результат достигнут. Однако необходимо удержать его, то есть сохранить ту ценность, которую принесло улучшение. Этот шаг гарантирует то, что прогресс организации не будет потерян, и она не вернется к предыдущему состоянию. Например, для увеличения продаж было улучшено качество товара. К намеченной дате KPI был выполнен - продажи взлетели на 40 % в сравнении с предыдущим периодом. Без реализации этого шага качество со временем снова упадет, и ценность, которую оно принесло, будет потеряна.
Для того чтобы сделать модель постоянного улучшения более эффективной, ITIL4 рекомендует комбинировать ее с принципами руководства, рассмотренными ранее. Принципы могут применяться на каждом шаге, однако среди них есть релевантные определенным шагам модели. В таблице 4.2 отражает соответствие принципов и шагов модели постоянного улучшения[1].
| Фокус на ценность | Начинай там, где ты есть | Прогрессируй итеративно с использованием обратной связи | Сотрудничай и способствуй прозрачности | Думай и работай целостно | Оптимизируй и автоматизируй | |
|---|---|---|---|---|---|---|
| Какого видение? | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Где мы сейчас? | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Где мы хотим быть? | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Как мы достигнем желаемого состояния? | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Действие | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Мы достигли того, чего хотели | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Как мы удержим результат? | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Из таблицы 4.2 видно, что все принципы можно применять на каждом из шагов модели постоянного улучшения, но некоторые из них наиболее актуальны в рамках конкретных шагов. Например, в рамках определения желаемого состояния, построения плана действий и его реализации важно применять принцип итеративного прогресса с использованием обратной связи.
В соответствии с теорией ограничений наиболее слабое звено в цепочке создания ценности определяет общую пропускную способность системы. Поэтому при планировании и приоритизации улучшений необходимо искать слабые места и работать в первую очередь над ними. Например, если на этапе развертывания возникает множество сбоев и именно эта деятельность является наиболее слабой частью - можно применить DevOps-принципы и различные технические практики, чтобы улучшить развертывание.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.