Разработка регламента выполнения процесса «Обеспечение послепродажного обслуживания» на примере компании ООО «Блэкпринт»

Содержание:

Введение

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

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

В принципе возможны следующие варианты послепродажного обслуживания:

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

- персоналом филиалов предприятия-производителя. Рекомендуется на этапе достаточного широкого распространения товара, когда число покупателей значительно увеличилось;

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

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

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

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

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

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

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

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

1.1 Описание предметной области. Постановка задачи.

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

Задача, спроектировать базу данных для сервисного центра, которая будет:

- помогать отслеживать наличие запчастей на складе;

- ускорить время реагирования на заявку клиента;

- оптимизировать рабочие процессы сервисного центра;

- уменьшить количество ошибок выполняемых сотрудниками;

- ввести форму документа формирования списка запчастей.

Структура компании на рисунке 1 и выглядит следующим образом.

Рисунок 1.

Основными задачами сервисного центра являются:

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

- Выполнение ремонтных работ печатного оборудования.

- Обеспечение работоспособности оборудования в течение эксплуатационного срока.

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

Отдел продаж продает расходные материалы к полиграфическому оборудованию.

Используемые в задаче документы:

- счет на оказание проведенных работ;

- счет на запасные части;

- заказ наряд;

- заявка на отгрузку;

- товарно - транспортная накладная.

Функционал сотрудников:

Начальник сервисного центра.

- координирует работу инженеров;

- принимает заявки от заказчиков по электронной почте;

- формирует списки запчастей для менеджеров;

- взаимодействие с клиентами (телефонные переговоры, встречи, решение спорных ситуаций и т.д.);

- выполняет поручения генерального директора;

- взаимодействует с бухгалтерией.

Менеджер по продажам расходных материалов.

- занимается продажей расходных материалов;

- выставляет счета на оплату заказчикам;

- формирует заказы поставщику.

Инженер.

- консультирует клиентов по вопросам эксплуатации оборудования по телефону и электронной почте;

- формирует списки запчастей;

- осуществляет выезды к заказчику для пускомонтажа, ремонта и наладки оборудования;

- производит доставку запчастей для ремонта;

- проводит обучающий инструктаж с заказчиком;

- оформляет заказ-наряд после успешного окончания работ.

Кладовщик.

- принимает и разгружает поступившие товары на склад;

- проверяет в ручную наличие запчастей на складе;

- формирует готовый заказ по заявке на отгрузку.

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

1.2 Выбор средства для моделирования бизнес-процессов

Создание бизнес процессов начинается с их описания. Описание бизнес процессов можно делать разными способами. Каждый имеет как плюсы, так и минусы. Можно выделить 3 типа описания — текстовый, табличный и графический. Естественно, в чистом виде они встречаются редко. В большинстве случаев мы комбинируем эти методы, в том или ином виде. Но если вы делаете упор, берет за основу, один из 3 элементов — описание текстом, таблицы или схему бизнес процесса, то тем самым, вы выбираете один из типов описания.
Управление бизнес процессами без их описания — крайне затруднительно.

Текстовое описание бизнес процессов.

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

Плюсы описания бизнес процессов текстом

• Очень просто сделать — просто садись и пиши.
• Не требует специальных навыков — темные времена прошли, теперь писать умеет каждый:)

Минусы

• Текст сложно обрабатывать — работа с массивами текста весьма сложна, ведь нам нужно найти суть, скрытую за словами.
• Затрудняет целостное восприятие процесса — читая вторую страницу, можно уже забыть, что было на первой. Очень тяжело читать текст, описывающий сложный, разветвленный процесс. Приходится постоянно возвращаться назад, чтобы понять о чем речь. В итоге восприятие картины целиком нарушается.
• В принципе сложно для восприятия — если текст готовит человек без писательских навыков, его прочтение превратиться в пытку. У каждого свой язык и , порой, он может быть очень сложен. Вы же встречали «плохие» книги? Описание процесса может быть еще хуже:)
• Сложно структурировать и анализировать — процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий, мы выполняем разные действия в процессе. А теперь представьте, каково это описывать текстом. Очень сложно сохранить простую структуру, когда у вас десяток «если» на одну страницу. В результате этого, анализ потребует от вас огромных усилий и титанической предварительной работы.

Описание бизнес процессов в виде таблиц.

Таблица это здорово! Таблицы я люблю. Их можно рассматривать часами… и не найти ответ на свой вопрос:) Шучу. На самом деле, описание бизнес процессов компании в виде связанных таблиц, не такая уж плохая идея. По крайней мере намного лучше текстового описания. Самая большая сложность заключается в том, чтобы подготовить хороший шаблон таблицы, в которую, собственно, потом уже внесут данные.

Плюсы описания бизнес процессов текстом в виде таблиц

• Относительно просто подготовить — подготовить шаблон не так сложно. Главное чтобы он был понятен тем, кто будет его заполнять. Кроме того, все программы для работы с таблицами (например Excel) позволяют добавлять описание к ячейкам таблицы. Используйте эту возможность для пояснений данных.
• Относительно просто заполнить шаблон — еще раз, если шаблон понятен, заполнить его не составит труда. Для этого не нужны специальные навыки и знания.
• Наличие структуры — таблица сама по себе уже предполагает некую структуру.
• Удобство обработки цифровых данных — с цифрами лучше всего работать в таблице. Так что для данного типа данных, этот тип описания подходит лучше всего. Данные в таблице, даже текстовые, гораздо удобнее сравнивать и анализировать.

Минусы:

• Не компактно — описание больших процессов, со всем множеством подпроцессов и элементов, будет выглядеть как «простыня». Компактным такой вид назвать сложно.
• Отсутствует необходимая детализация — для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит добиться необходимой детализации может стать не просто.
• Нет целостности восприятия — большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце — то лучше таблицы не придумать.
• Сложно отобразить ветвления — та же проблема, что и с текстом. Большое количество ветвлений, и , что важно, развитие процесса исходя из условий ветвления, довольно сложно отобразить наглядно.
• Требует подготовки — нужно потратить время на подготовку хорошего шаблона.

Описание в виде схемы, модели бизнес процесса.

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

Плюсы описания бизнес процессов в виде модели

• Простота восприятия — наш мозг устроен таким образом, что картинку мы воспринимаем быстрее чем что либо. Поэтому схему воспринимать очень просто. Мозг «фотографирует» схему и обрабатывает ее на бессознательном уровне, в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
• Целостность восприятия — 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности о его границах, основных элементах и т.д.  Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
• Необходимая и достаточная детализация — в тоже время, на схеме можно отобразить относительно больше количество деталей, без потери качества восприятия.
• Наглядное отображение ветвлений и путей развития процесса — правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
• Удобство автоматизации — многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.

Минусы

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

Семейство IDEF.

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

IDEF это не одна нотация, а целое семейство. Различаются они по порядковым номерам — IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Семейство IDEF безнадежно, морально, функционально устарело.
Дальше. Использовать модели бизнес-процессов, выполненных в IDEF крайне сложно. Как для изучения, так и для анализа. На рисунке 2 представлен пример схемы бизнес процесса. Рис. 2

Нотация имеет ограничения по количеству отображаемых на схеме процессов — не больше 7. В данном примере их 3. Отсюда возникает необходимость подстраивать описания под эти правила. Помимо этого, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес-процессов, так и «читателям».
В совокупности это влечет за собой огромное количество тяжелых для восприятия, крайне запутанных схем. Но есть и плюс — вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок схема будет ориентирована на лист формата А4 в альбомной ориентации. Т.е. распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающее моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своем, оно тоже устарело и не позволяет решать, актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес-процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами например, Microsoft Visio. Даже от руки, на листе бумаги, можно создать схему.
К слову, именно из потребности в автоматизации, т.е. переводу моделей бизнес-процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

eEPC.

Событийная цепочка процессов (EPC-диаграмма, англ. event-driven process chain) — тип блок-схемы, используемой для бизнес - моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия, и для улучшений бизнес-процессов.

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

На Рисунке 3 приведен пример нотации eEpc.

Рис. 3

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

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

Практически любое программное обеспечение, если только оно не заточено под конкретную нотацию, позволяет моделировать бизнес-процессы в нотации eEPC.
Платформа ARIS, предназначенная для комплексного управления бизнес-процессами, использует именно eEPC для моделирования процессов. Платформа позволяет задавать характеристики всех элементов в процессе, изменять их и оценивать влияние на систему. Т.е. проводить полноценное моделирование.

Нотация eEPC является не самым плохим решением для описания и моделирования бизнес-процессов.

BPMN.

Нотация по моделированию бизнес-процессов BPMN (The Business Process Modeling Notation) - это новый стандарт для моделирования бизнес процессов и сетевых услуг, который впервые был выпущен BPMI Notation Working Group в мае 2004 года. Последняя версия нотации BPMN 2.0 вышла в 2010 году.

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

Людям, занимающимся бизнесом, крайне удобно работать с бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых диаграмм в нотации BPMN, т.к. язык нотации понятен даже на уровне пользователя. При этом модели процессов, описанных в нотации BPMN, являются ИСПОЛНЯЕМЫМИ (т.е. реализуются в любой BPM-системе), а не только документируются.

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

отображается их взаимодействие. И это крайне важно.

Рис. 4 Модель процесса в нотации BPMN.

Дело в том, что наибольшие проблемы в бизнес-процессах, лежат на стыках работ разных исполнителей (ролей, процессов). Модели в нотации BPMN позволяют увидеть и проанализировать все взаимодействия.
Набор знаков в BPMN, достаточен для описания любого процесса и обозначения любых типов событий. Кстати, только в этой нотации существует разделение событий на события начала, окончания и промежуточные события. Почему это важно? Потому что процесс всегда начинается и заканчивается событием. Или событиями. Данное разделение позволяет сразу понять, с чего начинается и чем заканчивается процесс.
Существует разделение потоков на рабочие, информационные и ассоциации. Это позволяет разделять поток работ, потоки обмена информацией и потоки, определяющие принадлежность, к примеру, документов к тому или иному процессу. В свою очередь, данное разделение облегчает чтение и анализ моделей бизнес-процессов.
Помимо стандартных наборов значков, BPMN позволяет создавать свои, что позволяет адаптировать нотацию к любым потребностям.

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

Есть еще возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн.

Резюме — нотацию BPMN выбирает большинство профессионалов в управлении бизнес-процессами. Она наиболее современная и активно развивающаяся.

На основе выше изложенного, средство моделирования будет MS Visio.

Нотацией будет BPMN.

1.3 Моделирование бизнес - процессов "как есть".

Общий вид схемы деятельности сервисного центра представлена на рисунке 5. Схема реализована с помощью инструментария MS Visio 2007 в нотации BPMN.

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

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

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

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

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

Рисунок 5.

2.1 Предлагаемые мероприятия по улучшению бизнес-процессов

Эффективность работы сервисного центра включает в себя:

- время реагирования на заявку (от принятия до исполнения);

- быстрое и качественное исполнение заявки;

- наличие полного комплекта запчастей.

В нашем сервисном центре, существует следующие проблемы:

- длительное реагирование на заявку;

- долговременное оформление документов на получение запчастей инженером со склада.

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

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

Рисунок 6.

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

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

2.2 Моделирование бизнес-процессов «как должно быть

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

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

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

Рисунок 3. Схема "Как должно быть"

Заключение

В ходе данного курсового проекта, были построены схемы "Как есть" и выявлены недостатки и проблемы в бизнес процессах сервисного центра, и построена схема "Как должно быть".

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

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

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

Список использованной литературы

1.Маклаков С. В. BPwin и ERwin. CASE - средства разработки информационных систем. Диалог - МИФИ, 2000 г. - 256 с.

2. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес - процессов. Инфра - М, 2005 г. - 319 с.