Главная страница
Навигация по странице:

  • Инжиниринг и модель процесса

  • Построение технологической модели процесса

  • Методологии моделирования бизнес-процессов

  • Методология DFD .

  • Курс лекций операционный менеджмент


    Скачать 1.57 Mb.
    НазваниеКурс лекций операционный менеджмент
    АнкорOm_i_org_pov_chast_2_1_Op_men_sokrasch.doc
    Дата18.01.2018
    Размер1.57 Mb.
    Формат файлаdoc
    Имя файлаOm_i_org_pov_chast_2_1_Op_men_sokrasch.doc
    ТипКурс лекций
    #14434
    страница19 из 27
    1   ...   15   16   17   18   19   20   21   22   ...   27

    Операционные стратегии в сфере услуг

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

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

    Определяющим элементом треугольника сервиса является стратегия оказания услуги (рис. 4.2).

    Стратегия обслуживания







    КЛИЕНТ





    Обеспечивающая подсистема

    Сотрудники



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

    Сервисная стратегия начинается с выбора операционной направленности из следующих приоритетов:

    • внимательное и вежливое обращение с клиентами;

    • скорость и удобство предоставления услуги;

    • цена услуги;

    • разнообразие услуг;

    • уникальные навыки, формирующие предоставление услуг.

    Формирование сервисной стратегии включает следующие этапы:

    1. Определение оптимального уровня обслуживания клиента.

    2. Определение скорости и удобства обслуживания.

    3. Расчет рекомендуемой цены на услугу.

    4. Определение необходимого разнообразия оказания услуги.

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

    6. Определение требований к квалификации персонала.

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

    Инжиниринг и модель процесса

    Понятие «инжиниринг» заимствовано из инженерной деятельности, от англ. engineering – проектировать, изобретать, придумывать.

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

    Большинство специалистов рассматривают инжиниринг процессов как общее понятие, выделяя три его вида:

    1. прямой инжиниринг – проектирование новых бизнес-процессов «с чистого листа»;

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

    3. реинжиниринг – радикальное перепроектирование бизнеса и существующих бизнес-процессов.

    При инжиниринге используется моделирование.

    Модель процесса это представление (описание) ключевых характеристик существующего или проектируемого процесса. Объектом моделирования в организации являются организационная структура, цели и функции, материальные и информационные потоки, технологии бизнес-процессов, данные и знания сотрудников, необходимые для выполнения работы, а также коммуникационные сети и используемое программное обеспечение. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и порядок документооборота.

    Целью моделирования является систематизация знаний об организации и ее бизнес-процессах в наглядной графической форме удобной для аналитической обработки полученной информации.

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

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

    • организационную структуру;

    • функции подразделений и сотрудников;

    • распределение прав и обязанностей руководителей;

    • внутренние нормативные документы и технологии проведения операций;

    • требования к автоматизации выполняемых процессов и т.п.

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

    Построение технологической модели процесса

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

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

    • разделить процесс на отдельные результаты;

    • определить объемы работ процесса в терминах, понимаемых клиентами и участниками;

    • поддерживать документирование ответственности и отчетности по результатам;

    • формировать бюджет (финансирование) процесса;

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

    • снизить производственные риски за счет боле детального описания процесса;

    • отслеживать изменения и управлять ими до получения, требуемого результата.

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

    Технологическая модель при построении может опираться на следующие элементы процесса:

    • компоненты продукта процесса;

    • функциональные элементы деятельности;

    • этапы выполнения процесса;

    • элементы организационной структуры.

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

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

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

    1. определение конечных результатов (целей) процесса;

    2. определение основных работ и промежуточных результатов;

    3. интеграция модели с системой управления и контроля;

    4. согласование модели с участниками процесса и необходимая корректировка.

    Основные правила формирования технологической модели:

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

    2. Каждый более высокий уровень должен быть связан с более низким уровнем, а более низкий -- добавлять детальные элементы. Группу детальных элементов одного уровня должен объединять только один суммарный элемент (узел) на более высоком уровне.

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

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

    4. Детализация элементов модели должна выполняться до тех пор, пока не будут определены элементарные результаты (продукты), для каждой ветви процесса, направленные на достижение целей процесса в целом.

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

    При формировании технологической модели целесообразно использовать метод построения циклограммы сложного процесса (см. гл. 3).

    Наиболее распространенными ошибками, допускаемыми в ходе формирования технологической модели процесса, являются:

    • отсутствие стадии структуризации процесса и переход непосредственно к поиску и решению проблем процесса;

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

    • повторение элементов структуры процесса;

    • отсутствие интеграции структуры процесса с системой контроля и управления;

    • излишняя или недостаточная детализация;

    • отсутствие компьютерной поддержки;

    • отсутствие учета «неосязаемых» конечных продуктов, таких как услуги, информационное и программное обеспечение.

    Технологическая модель является основой:

    • для формирования структуры управления процессом;

    • для составления комплексного плана процесса, планирования объемов работ, стоимости, сроков и рисков, а также интеграции данных программных продуктов;

    • для организации производства процесса;

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

    • для управления содержанием процесса, так как формирует концептуальное представление о содержании процесса и определяет контрольные точки и элементы.

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

    Методологии моделирования бизнес-процессов

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

    Наиболее распространенными методологиями, используемыми при моделировании, являются: описание бизнес-процессов, описание потоков работ и описание потоков данных. Для более глубокого понимания сути бизнеса и его ключевых процессов используются графические способы описания процессов и специальные инструменты.

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

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

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

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

    Эти методологии эволюционировали по мере развития технических и программных средств.

    В 40-60-е гг. появились алгоритмические языки описания.

    В 60-е г. была разработана методология SADT - структурного анализа и проектирования.

    В 70-80-е гг. разработаны методологии DFD, ERD, IDEF, IDEF1X и др.

    В 90-е и последующие годы появились: UML -- универсальный язык моделирования; методология ARIS -- архитектура интегрированных информационных систем; методологии компаний Oracle, Baan, ReTrink, Rational и др.

    При инжиниринге участвуют специалисты двух типов – профессионалы в области реконструированного бизнеса и разработчики информационных систем. Опыт реинжиниринга показал, что по-настоящему успешное и новаторское внедрение информационных технологий является уникальным творческим процессом, в котором управляющие и специалисты технологи, знакомясь с методами информационных технологий, сами делают открытия относительно возможностей их использования в своем конкретном бизнесе. В то же время создание высококачественных информационных систем требует участия профессионалов в области информационных технологий. Возникает проблема поиска общего языка, интеграции современных технологий моделирования и разработки сложных систем: объективно-ориентированные методы, CASE-технологии, инженерия знаний, имитационное моделирование процессов и методы быстрой разработки приложений RAD (Rapid Application Development).

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

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

    Методология DFD. Стандарты DFD (Data Flow Diagramming) и WFD (Work From Diagram) содержат набор символов или обозначений, с помощью которых описывается бизнес-процесс. Язык DFD и WFD считают классическим.

    Методология DFD использует для описания бизнес-процессов диаграммы потоков данных. Диаграммы позволяют описывать потоки документов (документооборот) и потоки материальных ресурсов, т.е. движение материалов от одной работы к другой, и выявлять основные потоки данных. Описания могут создаваться как по функциональному признаку, так и на основе процессного подхода. В первом случае получаются схема обмена данными между подразделениями, а во втором – модели бизнес-процессов.

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

    Пример типовой модели описания бизнес-процессов верхнего уровня представлен на рис. 5.5.



    Рис. 5.5. Пример типового описания бизнес-процессов верхнего уровня в DFD
    На первом уровне схематично представляются основные компоненты деятельности организации. В нашем примере это: «закупки», «производство» и «сбыт». Каждый из этих блоков представляет декомпозицию бизнес-процессов второго уровня. В нашем случае бизнес-процесс второго уровня: «обработка заявок -- выбор поставщика – создание заказа на закупку и отслеживание его выполнения». Схема бизнес-процесса «выбор поставщика -- утверждение заявок -- составление сводной заявки» третьего уровня, представляет декомпозицию бизнес-процесса второго уровня «обработка заявок».

    Типовая модель описания бизнес-процессов нижнего уровня, используемая консалтинговыми компаниями на основе подхода «Swimmer lanes» представлена на рис. 5.6.
    1   ...   15   16   17   18   19   20   21   22   ...   27


    написать администратору сайта