Технологическая карта бизнес процесса это

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

· На верхних и средних уровнях:, ARIS VAD, IDEF0, DFD.

Условное обозначение: бизнес-процесс, подпроцесс.

· На нижних уровнях: ARIS eEPC, IDEF3, DFD, Cross Functional Flowchart.

Условное обозначение: процедура.

Бизнес-модель Банка включает детальные описания ключевых основных, обеспечивающих и управляющих бизнес-процессов банка в нотации Cross Functional Flowchart (Технологические карты).

Пример технологической карты процедуры нижнего уровня «Подготовка и выполнение операций инкассации банкомата» показан на Рис. 1.10.

Рис. 1.7. Дерево бизнес-процессов банка (верхний уровень)

Рис. 1.8. Дерево бизнес-процессов (детализация)

Рис. 1.9. Модель окружения процесса «Изготовление банковской карты»

Открытая пекарня. Что такое технологическая карта. Денис Машков.

Рис. 1.10. Технологическая карта процедуры «Подготовка и выполнение операций инкассации банкомата»

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

ТЕХНОЛОГИЧЕСКИЕ КАРТЫ ТОиР

Технологические карты ТОиР (техкарты) или стандартные операционные процедуры (СОП) — это пошаговое описание процесса выполнения работы с указанием используемых ресурсов, времени и других данных для достижения необходимых целей, поставленных при использовании технологических карт работ по обслуживанию и ремонту.

Достаточно непростой вопрос — нужны ли вообще для выполнения работ по обслуживанию техкарты? А если и нужны, то какой формы они должны быть, какую информацию содержать, для чего и как применяться?

Ответить на эти вопросы можно только понимая уровень зрелости компании, а также цели, которые ставятся перед оборудованием и его обслуживанием. Кроме этого, нужно понимать специфику оборудования и бизнес-процессы планирования и выполнения работ по обслуживанию, принятые в компании.

НА КАКОМ УРОВНЕ ЗРЕЛОСТИ КОМПАНИИ РЕКОМЕНДУЕТСЯ ВНЕДРЕНИЕ ТЕХКАРТ ТОИР

1. При невысоком уровне зрелости технического обслуживания, когда система управления ТОиР поддерживает тотальный контроль над временем выполнения работ с целью заставить людей делать работы всё быстрее и быстрее, техкарты ТОиР принесут больше вреда, чем пользы для предприятия и будут еще одним способом манипуляции премиями и фиктивными объёмами работ, трудозатратами. То есть для компаний с незрелыми процессами управления ТОиР внедрение техкарт, спущенное сверху директивой руководства — это зло.

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

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

На этом уровне зрелости могут разрабатываться достаточно подробные планы работ и стандартные операционные процедуры, где помимо прочего будут указываться параметры допустимых отклонений, полученных в результате каждой операции, точки двойного контроля и т.д. Минус таких тех.карт — это очень высокие трудозатраты на их составление и поддержание в актуальном состоянии, поэтому не стоит стремиться разработать техкарты ТОиР на все виды работ по обслуживанию оборудования.

Как всегда делать качественный продукт? // Технологические карты для бизнеса

То, что заносится в техкарты ТОиР — должно точно помогать достижению поставленных целей обслуживания, например:

• достижению требуемой безотказности;
• достижению заложенной долговечности;
• снижению неэффективного времени исполнителей работ;
• оптимизации затрат на запасные части, инструменты и материалы.

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

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

3. Компании, которые уже твердо встали на путь надежности и начинают повышать свою эффективность, в этом направлении могут значительно упросить свои техкарты или вовсе от них отказаться. Это становиться возможным из-за достаточной квалификации специалистов, в том числе и исполнителей работ. Кроме этого, на высоком уровне зрелости в компании появляются документы в виде сервисных отчётов, которые позволят фиксировать состояние оборудования и качество проведения ремонтных работ.

ПОЧЕМУ ПРОИЗВОДВТЕННЫЕ КОМПАНИИ ИЩУТ ПОДРЯДЧИКОВ ДЛЯ РАЗРАБОТКИ ТЕХКАРТ

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

1. «У нас нет свободных ресурсов для разработки техкарт».
2. «Мы не знаем, как разрабатывать техкарты».
3. «Мы не знаем, где брать нормативы времени выполнения работ».
4. «Мы хотели бы улучшить процедуры технического обслуживания и зафиксировать это в техкартах».
5. «У нас нет технической документации, на основании которой можно разрабатывать техкарты».
6. Если вы ищите подрядчиков для таких работ — укажите свой вариант ответа 🙂

Подобные вопросы сразу говорят о том, что уровень зрелости процессов компании еще не готов к внедрению техкарт ТОиР. Мы никогда не беремся за такие заказы, так как прежде, чем разрабатывать техкарты — необходимо навести порядок в процессах и в системе управления техническим обслуживанием.

КТО ДОЛЖЕН РАЗРАБАТЫВАТЬ ТЕХКАРТЫ

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

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

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

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

Давайте рассмотрим, какие шаги необходимо пройти компании для разработки техкарт выполнения стандартных работ.

ЭТАПЫ РАЗРАБОТКИ ТЕХНОЛОГИЧЕСКИХ КАРТ ТОИР

ШАГ 1. РАЗРАБОТКА СТАНДАРТНОЙ РАБОТЫ

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

1.1. Построение и улучшение Стандартной работы

Стандартные работы подготавливаются Инженерным обеспечением технического обслуживания совместно со специалистом по надежности и опытными рабочими.

Инструкции, содержащиеся в Стандартных работах, разрабатываются на основе:

• руководств производителя оборудования;
• спецификаций компонентов и материалов;
• чертежей;
• исторических данных об обслуживании оборудования;
• рекомендаций лучших передовых практик;
• требуемых компетенций персонала;
• доступных инструментов и вспомогательного оборудования;
• требований надёжности;
• требований производства;
• требований безопасности и т.д.

Одновременно с техкартами создаются процессы и инструменты для поддержания информации в них в актуальном состоянии.

1.2. Требования к составу техкарты

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

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

В состав СОП могут входить:

• Общее время выполнения работы
• Трудозатраты
• Требуемые компетенции (квалификация, грейды)
• Необходимые инструменты
• Требуемые отключения и остановки оборудования
• Функциональные характеристики оборудования
• Зап.части и материалы
• Допуски к работам, СИЗ
• Требования к качеству

Пример фрагмента СОП «Установка подшипника» с указанием требований по надежности и качеству работ

1.3. Определение навыков

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

ШАГ 2. НЕОБХОДИМО ПОДГОТОВИТЬ И УТВЕРДИТЬ ПОРЯДОК РАЗРАБОТКИ СТАНДАРТНЫХ ОПЕРАЦИОННЫХ ПРОЦЕДУР

На предприятии должны быть:

• Разработан и утвержден порядок разработки СОП
• Назначен ответственный за контроль процесса разработки СОП
• Ответственный за внесение изменений и поддержание СОП в актуальном состоянии

Разработана система управления СОП, в т.ч.:

• Состав СОП и требования к оформлению
• Перечень лиц для согласования и утверждения СОП
• Система регистрации СОП, в т.ч. система нумерации
• Система хранения
• Порядок пересмотра

Порядок, требования и правила заполнения и оформления СОП с примерами, в т.ч.:

• Титульного листа
• Листа выполнения операции
• Диаграммы Ганта
• Диаграммы перемещения
• Листа изменений
• Листа ознакомлений
• Порядок и пример ведения реестра СОП

Пример оформления титульного листа СОП

Пример оформления листа операций

Пример оформления диаграммы Гантта

ШАГ 3. РАЗРАБОТАТЬ И ВНЕДРИТЬ МЕТРИКИ УПРАВЛЕНИЯ ЭФФЕКТИВНОСТЬЮ ТЕХ.КАРТ (СОП)

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

ШАГ 4. ОБУЧЕНИЕ ПЕРСОНАЛА СТАНДАРТНОЙ РАБОТЕ

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

Для выполнения этого шага требуется специально подготовленный Инструктор:

• Инструктора лучше выбрать среди рабочих, он должен уметь не только правильно выполнять операции но и обучать.
• Инструктор выделяет цель и ее значение в процессе работы.
• Инструктор описывает основные задачи работы.
• Инструктор выделяет все проблемы безопасности, касающиеся процесса работы.
• Инструктор кратко описывает пошаговые, необходимые к выполнению правила эксплуатации для выполнения.
• Стандартной работы и одновременно предоставляет информацию о том, как сделать процесс легче, быстрее и надежнее.
• Инструктор показывает стажерам, как должна выполняться работа.
• Стажер описывает работу и затем выполняет её под присмотром инструктора. Необходимо начинать с простейших операций; только когда они выполнены надлежащим образом, стажер может переходить к выполнению более сложных задач.
• Стажер выполняет работу самостоятельно, но с замечаниями инструктора, если совершает ошибки.
• Стажер завершает обучение. Он принят в команду и он должен выполнить одну или несколько Стандартных работ, по которым он проходил обучение. Он также вовлечен в процессы улучшения.

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

Источник: toir.pro

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Cancel Create

dohq-doc-templates / techmap.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Cannot retrieve contributors at this time
92 lines (59 sloc) 17.3 KB

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents Copy raw contents

Copy raw contents

Технологическая карта производственного процесса

Более подробно про то, как мы пришли к пониманию необходимости использования технологической карты в DevOps процессах, можно почитать в статье на Хабре: «Управление хаосом: наводим порядок с помощью технологической карты»

Типовые задачи, производственные этапы, производственная технологическая цепочка

В работе DevOps-инженеров быстро накапливается множество однотипных и рутинных операций. От заказчиков в основном приходят так называемые типовые инженерные задачи, решение которых уже автоматизировано полностью или частично, не вызывает трудностей у исполнителей и не требует значительных объемов работ. Вы можете сами проанализировать такие задачи и выделить отдельные категории работ, или производственные этапы, этапы разбить на неделимые логические шаги, а из нескольких этапов получится производственная технологическая цепочка.

Простейший пример технологической цепочки — это этапы сборки, деплоя и тестирования каждого продукта компании. В свою очередь этап сборки может состоять из множества отдельных типовых шагов: выкачивание исходников из хранилища кода, скачивание и подготовка зависимостей и 3rd-party библиотек, юнит-тестирование и статический анализ кода, выполнение сборочного сценария, публикация артефактов в некоторое хранилище и, например, генерация релиз-нотов.

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

Если взять все этапы и шаги, попытаться закодировать их тегами и развернуть в одну цепочку, то она получится очень длинной и непонятной, как «хвост питона». Вот пример тегов этапов из реального процесса:

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

Это этапы сборки продуктов [Build], их деплоя на тестовые серверы [Deploy], тестирования [Test], продвижения сборок в релизные репозитории по итогам тестирования [Promote], генерации и публикации лицензий [License], публикации [Publish] на сервере обновлений и доставка с них до инфраструктуры заказчиков, инсталляция и обновление компонентов продуктов на инфраструктуре заказчика средствами Product Configuration Management [Install], а также сбор телеметрии [Telemetry] с установленных продуктов.

Кроме них можно выделить отдельные этапы: мониторинга состояния инфраструктуры [InfMonitoring], управления версиями исходного кода [SourceCodeControl], подготовки сборочного окружения [Prepare], управления проектами [Workflow], обеспечения команд средствами коммуникации [Communication], сертификации продуктов [Certification] и обеспечения самодостаточности CI-процессов [CISelfSufficiency] (например, независимости сборок от интернета).

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

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

Карта — это своеобразный классификатор. Она отражает крупные технологические части производства продуктов. С помощью неё команде DevOps-инженеров будет легче взаимодействовать с разработчиками и совместно планировать внедрение новых этапов автоматизации, а также понимать, какие трудозатраты и ресурсы (человеческие и «железные») для этого потребуются.

Более коротко, технологическая карта — это обобщенная картина производственного процесса, где отражены четко классифицированные блоки с типовой функциональностью. Самое главное: карта позволяет увидеть весь процесс целиком, крупными кусками с возможностью их детализации.

В каждой компании карта может выглядеть по своему. Например, вот так:

Структура технологической карты

Карта состоит из нескольких основных частей:

1. Область заголовков — здесь находится общее описание карты, вводятся базовые понятия, определяются основные ресурсы и результаты производственного процесса.
2. Область общей информации — здесь можно управлять отображением данных по отдельным продуктам, привести сводку и статистику по реализованным этапам и шагам в целом по всем продуктам.
3. Технологическая карта — табличное описание технологического процесса. На самой карте:
4. приводятся все этапы, шаги и их коды;
5. даются краткое и полное описания этапов;
6. указываются входные ресурсы и сервисы, используемые на каждом этапе;
7. указываются результаты каждого этапа и отдельного шага;
8. указывается зона ответственности по каждому этапу и шагу;
9. определяются технические ресурсы, например HDD (SSD), RAM, vCPU, и человеко-часы, необходимые для поддержки работ на данном этапе, как на текущий момент — факт, так и в будущем — план;
10. в ячейках карты для каждого продукта указывается, какие технологические этапы или шаги для него реализованы, планируются к внедрению, неактуальны или не реализованы.

Шаблон описания производственного этапа или шага

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

Элемент технологического конвейера Описание характеристики

Название или ключ:	Любое обозначение в виде [тега]
Тип (этап или шаг):	— / этап / шаг
Вид работы:	Короткое, в пару слов, описание видов работ выполняемых на этапе или шаге.
Краткое описание:	Короткий дайджест того, что происходит на данном этапе или шаге.
Подробное описание:	Подробное и детализированное описание этапа или шага технологического конвейера.
Входные ресурсы:	Какими ресурсами обеспечен данный этап или шаг, что требуется на входе для возможности его полной реализации?
Результаты:	Что получаем по итогу выполнения работ на данном этапе или шаге?
Зона ответственности и контакты:	Контакты ответственных за реализацию данного этапа или шага.
Ссылки на корп. стандарт:	Ссылки на инструкции и описания, скрипты реализации или стандартные инструменты, рекомендуемые DevOps-инженерами компании. Исполнителям должно быть понятно, по каким стандартам нужно реализовывать тот или иной этап и шаг.

Шаблон технологической карты

Табличку для техкарты можно создать в любом удобном для вас инструменте. Например, на скриншоте выше представлена карта, которую мы генерим для себя автоматически, в виде веб-странички (HTML + JS + CSS). Но для простоты можно использовать Excel-таблицы, этого вполне достаточно и более понятно большинству коллег.

Принятие решений на основе технологической карты

Изучив карту, возможно предпринять некоторые действия — в зависимости от роли сотрудника в компании (руководитель разработки, менеджер продукта, разработчик или тестировщик):

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

Резюмируя все вышесказанное

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

Источник: github.com