Ит обеспечение это бизнес процесс

5.3. Информационные технологии управления бизнес-процессами на предприятии

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

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

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

Как устроен процесс разработки? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains

Для сегодняшнего этапа развития характерно:

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

· они не четко описаны и не документированы;

· по мере выполнения процесса слишком часто происходит делегирование полномочий и никто не несет ответственности за процесс в целом;

· как правило, никто не владеет информацией о процессе в целом, т.е. четко не определен владелец процесса;

· не всегда понятно, кто же отвечает за конечный результат выполнения процесса;

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

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

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

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

Схема бизнес процесса Как нарисовать схему процесса в BPMN за 2 минуты?

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

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

Деятельность практически любой компании условно можно разделить на три вида:

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

Если рассматривать в качестве примера процесс продажи некоторого продукта или услуги, то:

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

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

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

Любой вид деятельности содержит эти три аспекта, каждый из которых можно в определенной мере развивать, совершенствовать и автоматизировать (рис. 5.2) . Интересно посмотреть, какая доля издержек связана с каждым из них. Согласно аналитикам из W

· хранилища данных и средства «добычи данных» для хранения и анализа данных, поступающих от приложений учета;

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

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

· лингвистические инструменты для поддержки запросов на естественных языках;

· — семантические сети для хранения смыслового содержания документов в виде сети действий над объектами, обеспечивающие мощный поиск документов на основе сличения с сетевыми образцами (например, все документы о превращении материалов в условиях высокой температуры);

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

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

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

контрольные Вопросы :

1. Что такое лизинг?

2. Какие существуют виды лизинга?

3. В чем особенность финансового лизинга?

4. В чем состоят преимущества лизинга как арендного механизма?

5. Что такое франчайзинг?

6. Дайте характеристику субъектов и объектов франчайзинга?

7. Какие бывают виды франчайзинговых сделок?

8. Что такое франчайзинговая сеть?

9. Дайте характеристику основных видов франчайзинговых сетей.

10. Что такое бизнес-процесс?

11. Дайте характеристику основных видов бизнес-процессов?

12. В чем особенность производственных бизнес-процессов?

13. В чем особенность учетных бизнес-процессов?

14. Какие виды информационных технологий применяются при управлении бизнес-процессами?

15. В чем особенность применения информационных технологий?

Источник: www.konsalter.ru

Управление мощностями и способ идентификации ИТ-услуг

Разбираясь с методическими вопросами сервисно-ресурсного планирования, я решил рискнуть и немного поспорить с авторами ITIL. На этот раз о том, как устроен процесс управления мощностями (Capacity management).

Авторы ITIL выделяют в управлении мощностями три подпроцесса:

• Business Capacity Management
• Service Capacity Management
• Resource Capacity Management

Думаю, я с таким делением не совсем согласен

Попробую обосновать. Представим себе три наиболее распространенных варианта ИТ-услуги (список таких вариантов не полон, более целостное изложение представлено в вебинаре Дениса Денисова «Формируем каталог ИТ-услуг: бизнес-процессы, ИТ-системы или функции?»):

1. ИТ-услуга – предоставление ресурса (каналов, вычислительных мощностей, хранилищ и так далее);
2. ИТ-услуга – обеспечение работоспособности информационных систем;
3. ИТ-услуга – ИТ-обеспечение исполнения и развития бизнес-процессов.

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

А теперь рассмотрим эти случаи более подробно.

1. ИТ-услуга как предоставление ресурса

В этом случае наш потребитель говорит на языке ресурсов. Например, мы предоставляем каналы передачи данных, наш потребитель – ИТ-подразделение компании, которой эти каналы нужны для решения своих задач. Или еще нагляднее — предоставление в аренду ПК.

Три подпроцесса управления мощностями в этом случае сокращаются до одного – Resource Capacity Management. Этот же подпроцесс можно называть Service Capacity Management, ведь услуга ассоциируется именно с ресурсом.

2. ИТ-услуга как обеспечение работоспособности ИТ-системы

Наш потребитель говорит на языке систем – какими пользуется, к каким необходим доступ, какие нужны характеристики скорости, надежности и так далее. Это довольно распространенный вариант отношений между ИТ-подразделением и другими подразделениями в пределах одной компании. Такой же диалог характерен для сценария SaaS.

Три подпроцесса управления мощностями в этом случае сокращаются до двух – Service Capacity Management (какие мощности нужны потребителю) и Resource Capacity Management (какие мощности для этого необходимо обеспечить на уровне ресурсов). При этом название Service Capacity Management можно заменить на System Capacity Management, ведь услуга связана именно с ИТ-системой.

3. ИТ-услуга как обеспечение исполнения и развития бизнес-процесса

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

Вот теперь (и только теперь) нужны все три подпроцесса. Но название Service Capacity Management нужно заменить на System Capacity Management, ведь услуга – это уже не про систему, а про бизнес-процесс.

Выводы

Следовательно, на основании предыдущих рассуждений, в процессе управления мощностями можно выделить три подпроцесса:

• Business Capacity Management
• System Capacity Management
• Resource Capacity Management

и сформулировать следующие границы их применения:

При этом термин Service Capacity Management как фиксированное название подпроцесса лучше не использовать, поскольку, в зависимости от того, как выделены наши услуги, деятельность по управлению мощностями услуг может «располагаться» на любом из уровней: Business, System или Resource Capacity Management.

Крамола? Но где я не прав?

Также по теме:

• Управление мощностями, как оно есть
• Коротко о бесконечном: управление мощностями ИТ
• Всюду они — теперь вместе!
• Простой, недорогой и эффективный способ измерения качества услуг
• ПО для планирования мощностей и финансов

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

CADmaster

Использование процессного подхода при внедрении информационных технологий

Скачать статью в формате PDF — 2.31 Мбайт

Главная » CADmaster №2(81) 2015 » Стандартизация Использование процессного подхода при внедрении информационных технологий

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

Билл Гейтс

Представим себе следующую ситуацию:

• руководство организации сформировало стратегический план развития, определило задачи и их приоритет. Предположим, что это комплексное решение (PDM, CRM, BIM, ERP или система PLM), автоматизирующее работу нескольких подразделений;
• ИТ-служба совместно со специалистами подразделений определила требования и сформировала план внедрения. После сравнения функционала, было приобретено нужное ПО.

Дальнейшие шаги, как правило, тоже стандартны:

• производится обучение сотрудников;
• выполняется пилотный проект (опционально);
• выполняется адаптация, техподдержка, внедрение

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

В результате выясняется: чтобы эффективно использовать новое решение, нужно:

• перестраивать свою работу под возможности продукта или же наоборот — настраивать его под свои задачи;
• интегрировать технологию с уже существующими на предприятии решениями (рис. 1).

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

Сложности интеграции ПО разных вендоров (производителей)

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

Попробуем применить системный поход к решению этой задачи и предположим, что базовая модель, применяемая при внедрении ИТ-решения представлена в виде треугольника «люди — процессы — технологии» (People — Process — Technology) (рис. 2).

Если перефразировать вынесенное в эпиграф высказывание Билла Гейтса, можно сказать следующее:

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

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

Треугольник взаимодействия «люди — процессы — технологии»

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

Прежде всего рассмотрим первую составляющую — «люди» («организация»). Для этого сравним существующие подходы к управлению предприятием (функциональный и процессный).

Функциональный подход

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

Пример функционального подхода: «Кто сшил костюм?» (А. Райкин)

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

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

Барьеры при взаимодействии между подразделениями

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

Процессный подход

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

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

Процессный подход к управлению предприятием

Выделение процесса как объекта позволяет:

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

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

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

В нашем случае потребители — это не только клиенты, которые используют вашу продукцию, но и сотрудники соседнего подразделения, получающие от вас продукты (информацию) или передающие вам ресурсы (рис. 6).

В настоящее время существует много подходов или стандартов описания бизнес-процессов, среди которых:

• IDEF0;
• IDEF3;
• DFD (Data Flow Diagram);
• WFD (Work Flow Diagram);
• BAAN;
• ORACLE;
• ARIS (Architecture of Integrated Information Systems);
• BPMN
  и др.

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

Я рекомендую нотацию BPMN 2.0 (рис. 7), которая используется для описания бизнес-процесса с целью его последующего моделирования. Это значит, что если есть описанный процесс в нотации BPMN 2.0, то его без программирования можно превратить в «исполняемую» бизнес-модель.

Модель и нотация бизнес-процессов (BPMN, Business Process Modeland Notation) — методология моделирования, анализа и реорганизации бизнес-процессов. Business Process Management Initiative (BPMI) разработана в 2005 году и поддерживается и развивается Object Management Group (OMG). В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» (EPC) или «национального» (IDEF0) стандарта, BPMN получила международный статус — Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology — Object Management Group. Business Process Model and Notation».

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

• объекты потока (Flow Objects);
• данные (Data);
• зоны ответственности (Swimlanes);
• соединяющие элементы (Connecting Objects);
• артефакты (Artifacts).

Пример бизнес-процесса в нотации BPMN 2

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

Рассмотрим ряд проблем, связанных с внедрением процессного подхода в организациях:

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

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

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

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

Процессный подход к внедрению информационных технологий

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

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

Первый уровень диаграммы (бизнес-уровень)

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

На диаграмме показано (рис. 9):

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

Уровень 1: описание бизнес-процессов с указанием ролей

Бизнес-процесс создания нового изделия показан упрощенно. В нашем процессе есть задача : создать 3D-модель. Для описания этой задачи переходим на следующий уровень.

Второй уровень диаграммы (основан на интеграции программного обеспечения)

Этот уровень связан с первым уровнем диаграммы. Нумерация показывает, что это второй уровень описания процессов. Целью данного уровня является показать, как и в каком ПО выполняется задача, а именно — создать 3D-модель. На приведенной схеме (рис. 10) показано, как взаимодействует программное обеспечение между собой: ПО , ПО , ПО . Результатом является выполнение задачи уровня , а именно — «3D-модель создана».

Уровень 2: описание процессов с указанием ПО

Для описания задачи 1.1 «Сформировать исходные данные» переходим на следующий, третий уровень.

Третий уровень диаграммы: детальное описание действий пользователя для получения результата

На этом этапе детально описываем, что нужно сделать и какие действия следует совершить пользователю, чтобы сформировать исходные данные. На рис. 11 мы видим, что исполнитель сначала выполняет задачу 1.1.1, а затем согласовывает информацию с руководителем. Результат: «Исходные данные сформированы».

Уровень 3: детальное описание процессов