Вы здесь

ИТ-архитектура. Практическое руководство от А до Я. Первое издание. Концепция Информационных Систем Управления (MIS) и интеграции данных (Вадим Алджанов)

Концепция Информационных Систем Управления (MIS) и интеграции данных

Общие Положения

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

Информационные Системы Управления (Management Information System MIS) является общим, собирательным термином, которая охватывает информационные системы широкой категорией, имеющиеся в компании, на основе которой руководство компании может организовать коммерческую или иную бизнес деятельность и принимать решения.

Причины появления Автоматизированных Систем Управления (АСУ)

Рассмотрим для примера работу небольшой компании по продаже бананов. Имеется штат офисных сотрудников каждый из которых выполняет свои функциональные обязанности: менеджер по продажам ведет учет покупателей, логистик – учет доставки, бухгалтер – учет и т п. У каждого из есть компьютер с установленным офисным приложением, например, Microsoft Excel – «убийца ERP систем». Подразумевается навыки хорошего владения продуктом, что для бухгалтеров «старой закалки» являлось нормой. У тех, чей уровень знания Excel ниже, локально на компьютере установлена подходящая программа. Ведение учета, построение сложной аналитики, предоставление отчетов руководству. Помощник руководителя, собирает отчеты у менеджеров, формирует консолидированные отчеты и отправляет руководству. Пересчитать себестоимость по FIFO или LIFO, придумать новую формулу расчета скидок, сценарии продаж и т п. – «без проблем»: быстро, не дорого и правильно. Не одна ERP с целым штатом консультантов, на мощных серверах и огромными расходами не сможет быстрее и правильнее. Все идет прекрасно, контора растет, до того момента пока:

•один человек перестает справляется, и требуется совместное редактирование Excel файлов двум и более сотрудникам

•Возможности Excel ограничены

•Потребность в скорости обмена актуальными данными возрастает


Минусы автономной работы стали перевешивать плюсы и тормозить бизнес. Нужно что-то делать?

Потребность в автоматизации управленческих процессов впервые была осознана в конце 60-х – начале 70-х годов, когда стало ясно, что управление крупной корпорацией подчиняется тем же законам, что и любая бюрократическая структура. Один из законов Паркинсона гласит: «штат организации никак не связан с объемом выполняемой ею работы». Иными словами, с ростом численности управленческого персонала КПД его работы падает до нуля.

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

Категории Информационных Систем Управления (Management Information Systems)

Назначение Автоматизированных Систем Управления:

•Обеспечить руководство инструментами, помогающими в принятии решений стратегического, тактического и оперативного управления.

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




Основные термины и определения приводятся в Словаре APICS. Именно в этом издании содержится наиболее полное и точное определения систем:

MPS (Master Planning Schedule)

Хорошо известная методология «объемно-календарного планирования». Является базовой практически для всех планово-ориентированных методологий. Применяется в основном в производстве, но также может использоваться и в других отраслях бизнеса, например, дистрибуции.

MRP (Material Requirements Planning) – Автоматизированное планирование потребности сырья и материалов для производства

Методология планирования потребности в материальных ресурсах, заключающаяся в определении конечной потребности в ресурсах по данным объемно-календарного плана производства. Ключевым понятием методологии является понятие «разузлование», т. е. приведение древовидного состава изделия к линейному списку (Bill of Materials), по которому планируется потребность и осуществляется заказ комплектующих. Ее усовершенствованная версия, Closed Loop MRP (планирование потребности в материалах в замкнутом цикле), позволила динамически корректировать планы закупок при возникновении нештатных отклонений от них.

CRP (Capacity Requirements Planning) – Планирование производственных ресурсов

Данная концепция схожа с MRP, но вместо единого понятия состава изделия она оперирует такими понятиями, как «обрабатывающий центр», «машина», «рабочие ресурсы», ввиду чего технически реализация CRP более сложна. Обычно применяется совместно с MRP ввиду тесной логической связи при планировании. Методологии MRP/CRP применяются в АСУП производственных предприятий.

FRP (Finance Requirements Planning) – Планирование финансовых ресурсов


MRPII (Manufacturing Resources Planning)

Планирование и управление всеми производственными ресурсами предприятия:

•сырьем,

•материалами,

•оборудованием,

•трудозатратами.

•Планирование производства.


Интегрированная методология, включающая MRP/CRP и, как правило, MPS и FRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана. Устраняет серьезный недостаток MRP: суть которого в том, что, рассчитывая потребность в материалах, не учитываются производственные мощности, их загрузку, стоимость рабочей силы и т. д. Концепция MRP II позволял планировать все производственные ресурсы предприятия (сырье, материалы, оборудование, персонал и т. д.). Впоследствии концепция MRP II развивалась, и к ней постепенно добавлялись возможности по учету остальных затрат предприятия – появилась концепция ERP (Enterprise Resource Planning – Планирование ресурсов предприятия), называемая иногда также планированием ресурсов в масштабе предприятия (Enterprise-wide Resource Planning).

Развитием концепций автоматизированного управления занимается американская некоммерческая организация APICS (American Production and Inventory Control Society). По стандарту APICS, MRP II включает следующие функции:

•Sales and Operation Planning – Планирование продаж и производства

•Demand Management – Управление спросом

•Master Production Scheduling – Составление плана производства

•Material Requirement Planning – Планирование потребностей в сырье и материалах

•Bill of Materials – Спецификации продукции

•Inventory Transaction Subsystem – Складская подсистема

•Scheduled Receipts Subsystem – Отгрузка готовой продукции

•Shop Flow Control – Управление производством на цеховом уровне

•Capacity Requirement Planning – Планирование производственных мощностей

•Input/output control – Контроль входа/выхода

•Purchasing – Материально-техническое снабжение

•Distribution Resource Planning – Планирование запасов сбытовой сети

•Tooling Planning and Control – Планирование и управление инструментальными средствами

•Financial Planning – Финансовое планирование

•Simulation – Моделирование

•Performance Measurement – Оценка результатов деятельности


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

Стандарт MRP II делит сферы отдельных функций (процедур) на два уровня:

•Необходимый

•Опциональный


Для того, чтобы программное обеспечение было отнесено к классу MRP II, оно должно выполнять определенный объем необходимых (основных) функций (процедур). Некоторые поставщики ПО приняли различный диапазон реализаций опциональной части процедур этого стандарта. Результаты использования интегрированных систем стандарта MRP II:

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

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

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

•реальное сокращение материальных ресурсов на складах;

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

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

•финансовое отражение деятельности предприятия в целом;

•значительное сокращение непроизводственных затрат;

•защита инвестиций, произведенных в информационные технологии;

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


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

ERP (Enterprise Resources Planning) – Управление ресурсами предприятия

К свойствам MRPII добавилось управление финансовыми ресурсами, маркетинг. ERP концепция – первая направленная на управление бизнесом, а не только производства, как MRP. Концепция бизнес-планирования. Под ERP подразумевается «интегрированная» система, выполняющая функции, предусмотренные концепциями MPS-MRP/CRP-FRP. Важным отличием от методологии MRPII является возможность «динамического анализа» и «динамического изменения плана» по всей цепочке планирования. Конкретные возможности методологии ERP существенно зависят от программной реализации. Концепция ERP более «размыта», чем MRPII. Если MRPII имеет явно выраженную направленность на производственные компании, то методология ERP оказывается применимой и в торговле, и в сфере услуг, и в финансовой сфере. Класс ERP, в отличие от MRP и MRP II, для которых имеются строгие определения и формализованные перечни требований, описан только на уровне концепции. Поэтому утверждения о том, что-такая-то система относится к классу ERP, строго говоря, является рекламным утверждением, или, в лучшем случае, экспертным заключением.




В основе ERP лежит концепция ERP: принцип создания единого хранилища данных (repository), содержащего всю деловую информацию, накопленную организацией в процессе ведения деловых операций, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от системы к системе. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями. Концепция ERP стала очень известной в производственном секторе, поскольку планирование ресурсов позволило сократить время выпуска продукции, снизить уровень товарно-материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Стандарт ERP позволил объединить все ресурсы предприятия, таким образом, добавляя управление заказами, финансами и т. д. Когда в список учитываемых при планировании ресурсов добавились другие, в частности, финансовые, появился термин ERP (Enterprise Resource Planning) – планирование ресурсов в масштабе предприятия.

Различие между концепциями MRP II и ERP заключается в том, что первая ориентирована на производство, а вторая – на бизнес. Например, такие вещи, как условия кредитования заказчика по отгрузке готовой продукции, попадают в поле зрения ERP, но не MRP II. Инструментарий OLAP, средства поддержки принятия решений – принадлежности ERP, но не MRP/MRP II систем.

В соответствии со Словарем APICS, термин «ERP-система» может употребляться в двух значениях:

•Во-первых, это – информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов.

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


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

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

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

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

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

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

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

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


ERP не является вершиной эволюции. Фундаментальное ограничение систем ERP: они автоматизируют внутреннюю деятельность предприятия так называемый «back-office».

CSRP (Customer Synchronized Resources Planning) – Управление, ориентированное на взаимодействие с клиентами

Управление, ориентированное на взаимодействие с клиентами, включает в себя получение заказов, разработку планов, проектов и заданий, техподдержку. Практически, CSRP=ERP+CRM. Планирование ресурсов, синхронизированное с покупателем. CSRP включает в себя полный цикл – от проектирования будущего изделия с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Суть CSRP состоит в том, чтобы интегрировать покупателя в систему управления предприятием. При этом не отдел продаж, а сам покупатель размещает заказ на изготовление продукции, сам отвечает за правильность его исполнения и при необходимости отслеживает соблюдение сроков производства и поставки. Предприятие же может очень четко отслеживать тенденции спроса на его продукцию.

Концепция CSRP – Customer Synchronized Resource Planning (Планирование ресурсов, синхронизированное с покупателем) – охватывает также и взаимодействие с клиентами: оформление наряд-заказа, тех задание, поддержка заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы интегрировать Заказчика (Клиента, Покупателя и пр.) в систему управления предприятием. То есть не отдел сбыта, а сам покупатель непосредственно размещает заказ на изготовление продукции – соответственно сам несет ответственность за его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может очень четко отслеживать тенденции спроса и т. д. На расширение функциональности на сферу взаимодействия предприятия с его заказчиками нацелена концепция CSRP. Корпоративные ресурсы, охватываемые CSRP-системой, обслуживают такие этапы производственной деятельности, как проектирование будущего изделия с учетом специфических требований заказчика, гарантийное и сервисное обслуживание.

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

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

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

ERPII (Enterprise Resource & Relationship Processing) – Управление внутренними ресурсами и внешними связями предприятия

Новая ревизия концепции ERP. Можно считать, что, ERPII=ERP+CRM+SCM. Пока что данный класс применяется нечасто. Основная идея ERP II заключается в выходе за рамки задач по оптимизации внутренних процессов организации: кроме интеграции таких традиционных для ERP систем областей деятельности предприятия, как управление финансами, бухгалтерский учет, управление продажами и покупками, отношения с дебиторами и кредиторами, управление персоналом, производство, управление запасами, системы класса ERP II позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. По определению, данному Gartner Group ERP II, – это бизнес-стратегия предприятия, принадлежащего к определенной отрасли, и набор ключевых для данной отрасли приложений, помогающих клиентам и акционерам компаний увеличивать стоимость бизнеса за счет эффективной ИТ-поддержки и оптимизации операционных и финансовых процессов как внутри своего предприятия, так и во внешнем мире – в рамках сотрудничества с другими корпорациями. Основная идея ERP II заключается в выходе за рамки задач по оптимизации внутренних процессов организации: кроме интеграции таких традиционных для ERP систем областей деятельности предприятия, как управление финансами, бухгалтерский учет, управление продажами и покупками, отношения с дебиторами и кредиторами, управление персоналом, производство, управление запасами, системы класса ERP II позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. Функции и преимущества систем, которые реализованы в ERPII:

•Управление взаимоотношениями с клиентами (CRM).

•Управление послепродажным обслуживанием клиентов.

•Электронная коммерция.


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

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

Электронная коммерция. Для продвижения своего бизнеса в Интернет необходимо, прежде всего, выстроить и отработать свои бизнес процессы до открытия Интернет представительства. Отсутствие «надежного тыла» становиться серьезной проблемой для компании. Это обусловлено тем, что при обычной схеме работы задача часто решается следующим образом: создается каталог продукции с описанием товаров и интерактивной формой заказа, клиент заказывает товар и ждет его доставки. Однако зачастую, осуществляя заказ, клиент, да и сами менеджеры, не имеют понятия, есть ли товар на складе и в случае отсутствия, сколько времени понадобится, чтобы доставить товар на склад, а затем переправить его клиенту. Более того, если единожды компания осуществляла специальный заказ для клиента, данные об этом не сохраняются, и при вторичном заказе компания вновь обрабатывает его как новый. Это приводит к простоям, затягивает сроки доставки заказов, что, в конечном счете, влечет за собой полное разочарование клиентов. Функциональность систем ERP II, в свою очередь, позволяют контролировать склад, закупки и поставки и организовывать систему работы оптимальным образом. Помимо оптимизации рабочих процессов, решения ERP II позволяет создать клиентскую базу, хранить и анализировать данные по предпочтениям. Компания также получают возможность прогнозировать сроки последующих заказов постоянных покупателей и предоставлять более персонализированный сервис, что служит выработке приверженности покупателей к сотрудничеству и установлению длительных отношений с клиентами. Таким образом, использование ERP-систем при ведении электронной торговли позволяет компаниям добиться преимущества по отношению к конкурентам. С появлением на рынке систем ERP II, ориентированных на средние предприятия, компании получают возможность развивать торговые площадки в Интернет, которые оптимально будут отвечать их нуждам – обеспечивать электронный документооборот, контролировать движение заказов и т. д. Это позволит компаниям использовать свои Интернет – ресурсы для взаимодействия с поставщиками или дистрибьюторами. Использование систем класса ERP II в данном случае позволяет оптимизировать процессы, как закупок, так и продаж. Информация о заказах, полученных через Интернет, интегрируется с данными склада, отделов доставки, продаж, сервисных центров, что позволяет создать единый профиль клиента, эффективно обрабатывать заказы и быстро отвечать на них, создавать и хранить данные обо всех его обращениях, анализировать их и прогнозировать новые обращения. Клиент, в свою очередь, отправив заказ через Интернет – представительство, получает возможность контролировать процесс обработки заказа: автоматическое уведомление о его принятии и начале работы, данные о подготовке заказа, когда его заявка получена складом, сведения об отгрузке, когда заказ сформирован и отправлен, а также пакет необходимых документов. Аналогично используется система при закупках. Менеджер по закупкам через систему получает доступ к каталогу товаров поставщика, выбирает необходимые товары и отправляет заказ. Возможны варианты, когда система автоматически формирует заказ на покупку, учитывая оптимальные объемы закупок, текущие потребности, необходимые сроки поставки и в стандартном формате пересылает поставщику. Система у поставщика обрабатывает полученный заказ, вычисляет срок поставки и посылает уведомление о ходе выполнения заказа.

SCM (Supply Chain Management) – Управление отношениями с поставщиками

Управление цепочками поставок. Концепция SCM придумана для оптимизации управления логистическими цепями и позволяет существенно снизить транспортные и операционные расходы путем оптимального структурирования логистических схем поставок. Концепция SCM поддерживается в большинстве систем ERP- и MRPII-класса.

CRM (Customer Relationship Management) – Управление отношениями с заказчиками

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

PLM (Product Lifecycle Management) – управление жизненным циклом продукта


CAD/CAM/САЕ/PDM (Computer Aided Design / Computer Aided Manufacturing / Computer Aided Engineering / Project Data Management)

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

MES (Manufacturing Execution System) Система управления производственными процессами

Специализированное прикладное программное обеспечение, предназначенное для решения задач синхронизации, координации, анализа и оптимизации выпуска продукции в рамках какого-либо производства. Существует несколько формулировок определения MES систем. MES – информационная и коммуникационная система производственной среды предприятия (определение APICS). MES – автоматизированная система управления и оптимизации производственной деятельности, которая в режиме реального времени: инициирует, отслеживает, оптимизирует, документирует производственные процессы от начала выполнения заказа до выпуска готовой продукции (определение MESA International). MES – интегрированная информационно-вычислительная система, объединяющая инструменты и методы управления производством в реальном времени. MES-системы относятся к классу систем управления уровня цеха, но могут использоваться и для интегрированного управления производством на предприятии в целом. Функции c-MES:

•RAS (Resource Allocation and Status) – контроль состояния и распределение ресурсов.

•DPU (Dispatching Production Units) – диспетчеризация производства (координация изготовления продукции).

•DCA (Data Collection/Acquisition) – сбор и хранение данных.

•LUM (Labor/User Management) – управление людскими ресурсами.

•QM (Quality Management) – управление качеством.

•PM (Process Management) – управление процессами производства.

•PTG (Product Tracking & Genealogy) – отслеживание и генеалогия продукции.

•PA (Performance Analysis) – анализ эффективности.

•Advanced Planning & Scheduling (APS) – составления производственных расписаний в рамках всего предприятия,

•Enterprise Asset Management (EAM) – отвечает за управление техническим обслуживанием и ремонтами.


В зависимости от характера, масштаба и особенностей производственных структур и самих систем, существуют различные комбинации сочетаний корпоративных систем ERP, APS и MES в общей структуре информационных систем управления предприятием.

SCADA (Supervisory Control and Data Acquisition System) – система сбора данных и оперативного диспетчерского управления технологических процессов

Хотелось бы подчеркнуть, что в названии присутствуют две основные функции, возлагаемые на SCADA_систему:

сбор данных о контролируемом технологическом процессе;

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

B2C (Business to Customer) и B2B (Business to Business)

обозначения широких классов программных продуктов, обслуживающих взаимоотношения предприятий с покупателями (B2C) и между собой (B2B). Пример B2C-системы – онлайновый интернет-магазин. К классу B2B относятся SCM и CSRP-решения. Технологии B2B в настоящее время переживают настоящий бум. Аналитики соревнуются в предсказании астрономических сумм, которые будут потрачены на них в ближайшие годы. Этот бум связан с вступлением развитых стран в постиндустриальный период. Во все больших масштабах крупные корпорации стремятся избавляться от производства, оставляя за собой исследования, проектирование, маркетинг и продажи. Производство же размещается на фабриках, расположенных в странах с дешевой рабочей силой, и являющихся независимыми предприятиями-подрядчиками. Понятно, что такая схема ведения бизнеса невозможна без совершенных B2B-систем.

OLAP (Online Analytical Processing – аналитическая обработка данных в реальном времени)

Представляет собой мощную технологию обработки и исследования данных. Системы, построенные на основе технологии OLAP, предоставляют практически безграничные возможности по составлению отчетов, выполнению сложных аналитических расчетов, построению прогнозов и сценариев, разработке множества вариантов планов. В основе работы OLAP системы лежит обработка многомерных массивов данных. Многомерные массивы устроены так, что каждый элемент массива имеет множество связей с другими элементами. Чтобы сформировать многомерный массив, OLAP система должна получить исходные данные из других систем (например, ERP или CRM системы), или через внешний ввод. Пользователь OLAP системы получает необходимые данные в структурированном виде в соответствии со своим запросом. Исходя из указанного порядка действий, можно представить структуру OLAP системы. В общем виде, структура OLAP системы состоит из следующих элементов:

•База данных является источником информации для работы OLAP системы. Вид базы данных зависит от вида OLAP системы и алгоритмов работы OLAP сервера. Как правило, используются реляционные базы данных, многомерные базы данных, хранилища данных и т. п.

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

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


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

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

•реляционные базы данных. Эти базы данных используются при совместной работе OLAP системы с CRM системой или ERP системой. Данные хранятся на сервере этих систем в виде реляционных баз данных или хранилищ данных. OLAP сервер обращается к этим базам данных для формирования необходимых многомерных структур и проведения анализа.

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


В зависимости от метода хранения и обработки данных, все OLAP системы могут быть разделены на три основных вида:

•ROLAP (Relational OLAP – реляционные OLAP системы) – этот вид OLAP системы работает с реляционными базами данных. Обращение к данным осуществляется напрямую в реляционную базу данных. Данные хранятся в виде реляционных таблиц. Пользователи имеют возможность осуществлять многомерный анализ как в традиционных OLAP системах. Это достигается за счет применения инструментов SQL и специальных запросов. Одним из преимуществ ROLAP является возможность более эффективно осуществлять обработку большого объема данных. Другим преимуществом ROLAP является возможность эффективной обработки как числовых, так и текстовых данных. К недостаткам ROLAP относится низкая производительность (по сравнению с традиционными OLAP системами), т. к. обработку данных осуществляет сервер OLAP. Другим недостатком является ограничение функциональности из-за применения SQL.

•MOLAP (Multidimensional OLAP – многомерные OLAP системы). Этот вид OLAP систем относится к традиционным системам. Отличие традиционной OLAP системы, от других систем, заключается в предварительной подготовке и оптимизации данных. Эти системы, как правило, используют выделенный сервер, на котором осуществляется предварительная обработка данных. Данные формируются в многомерные массивы – OLAP кубы. MOLAP системы являются самыми эффективными при обработке данных, т. к. они позволяют легко реорганизовать и структурировать данные под различные запросы пользователей. Аналитические инструменты MOLAP позволяют выполнять сложные расчеты. Другим преимуществом MOLAP является возможность быстрого формирования запросов и получения результатов. Это обеспечивается за счет предварительного формирования OLAP кубов. К недостаткам MOLAP системы относится ограничение объемов, обрабатываемых данных и избыточность данных, т. к. для формирования многомерных кубов, по различным аспектам, данные приходится дублировать.

•HOLAP (Hybrid OLAP – гибридные OLAP системы). Гибридные OLAP системы представляют собой объединение систем ROLAP и MOLAP. В гибридных системах постарались объединить преимущества двух систем: использование многомерных баз данных и управление реляционными базами данных. HOLAP системы позволяют хранить большое количество данных в реляционных таблицах, а обрабатываемые данные размещаются в предварительно построенных многомерных OLAP кубах. Преимущества этого вида систем заключаются в масштабируемости данных, быстрой обработке данных и гибком доступе к источникам данных.


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

•WOLAP (Web OLAP). Вид OLAP системы с поддержкой web интерфейса. В этих системах OLAP есть возможность обращаться к базам данных через web интерфейс.

•DOLAP (Desktop OLAP). Этот вид OLAP системы дает возможность пользователям загрузить на локальное рабочее место базу данных и работать с ней локально.

•Mobile OLAP. Это функция OLAP систем, которая позволяет работать с базой данных удаленно, с использованием мобильных устройств.

•SOLAP (Spatial OLAP). Этот вид OLAP систем предназначен для обработки пространственных данных. Он появился как результат интеграции географических информационных систем и OLAP системы. Эти системы позволяют обрабатывать данные не только в буквенно-цифровом формате, но и в виде визуальных объектов и векторов.


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

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

•проведение многовариантного анализа. Применение OLAP системы позволяет получить множество сценариев развития событий на основе набора исходных данных. За счет инструментов анализа можно смоделировать ситуации по принципу «что будет, если».

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

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

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

ABS (Automated Banking System, Core Banking System) – Автоматизированная Банковская Программа

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

Классификация Управления Организацией

Функционально Ориентированная Организация Управления

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

•Слабые горизонтальные связи между функциональными структурными единицами,

•Сильные вертикальные линии связи внутри одной функциональной структуры, типа «начальник-подчиненный».


Подчиненный отвечает только за порученные ему функции и, возможно, за деятельность своего подразделения в целом. Функции и результаты работы параллельных структурных единиц его не очень интересуют. Данные структурируются по функциональному назначению структурных подразделений компании. Как пример, для небольшой компании в качестве ИТ решения может быть выбрано решение 1С «Бухгалтерия» для ведения хозяйственной деятельности, бухгалтерского и Управленческого учета. Все остальные функциональные подразделения используют данное решение для автоматизации операционной деятельности исходя из имеющегося функционала. Для крупной компании для финансового департамента может быть выбрано решение, например, Программа 1С конфигурация «Бухгалтерия», а для Отдела Кадров выбрано решение 1С конфигурация «Управление Сотрудниками», отвечающие требованиям подразделений.

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

Процесс Ориентированная Организация Управления

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

•Горизонтальные связи между структурными единицами при таком подходе сильнее

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


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

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

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

Классификация Информационных Систем с точки зрения ИТ

Функционально Ориентированная Информационная Система

Как видно из особенностей функционально ориентированного подхода к управлению организацией, информационная система предприятия выбирается исходя из требований функционального подразделения компании. Так для примера, была выбрана система «1С конфигурация Бухгалтерия» покрывающая требования по ведению Управленческого, Бухгалтерского и Налогового Учета в процессе ведения коммерческой и хозяйственной деятельности. Деятельность остальных подразделений (отдела кадров, отдела продаж, администрации и т п) по возможности встраивается в имеющуюся информационную систему с использованием «базового» функционала. В процессе развития компании, информационная система модернизируется, обновляется и в целом удовлетворяет требованиям бизнеса. ИТ департамент обеспечивает внедрение и сопровождение системы. На каком-то этапе своего развития отдел продаж или маркетинга, нуждается в дополнительном функционале, отсутствующем в имеющейся системе. Перед руководством компании, как и перед руководителем ИТ департамента, возникает вопрос: сменить текущую систему на новую, в которой помимо имеющегося функционала, так же присутствуют функции, требуемые со стороны отдела продаж. Бухгалтерия, а возможно и другие подразделения, возможно будут против, как и руководитель ИТ по следующим причинам:

•Текущая система удовлетворяет требования большинства подразделений компании

•Имеется наработанная практика работы с программой со стороны бизнеса

•Имеется наработанная практика работы с программой со стороны ИТ (баги, ошибки, навыки сопровождения и т п)


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

•Постановка технического задания по имеющимся функциям

•Постановка технического задания по новым функциям

•Реинжиниринг бизнес процессов для адаптации к новой системе

•Наличие ресурсов для внедрения и сопровождения

•Как новое решение вписывается в имеющуюся ИТ инфраструктуру

•План внедрения новой информационной системы без прерывания бизнеса

•План миграции информации из старой системы в новую

•Обучение персонала

•Вопросы по поддержке

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


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

•Расходы на внедрение новой системы (как прямые, так и косвенные расходы времени и денег)

•Не удобство для пользователей (интерфейс другой, формы и процессы могут отличатся значительно)

•Возрастания количества ошибок и проблем во времени эксплуатации системы пользователями (не знают, ошибки и т п)

•Время устранения проблем со стороны ИТ увеличивается (ИТ не имеет навыков по сопровождению системы)

•Вопросы по миграции данных из старой системы в новую


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

Как результат, скорее всего будет принято решение, по приобретению отдельного решения с имеющимся функционалом, удовлетворяющим требования отдела продаж. Например, Microsoft Navision CRM.

Некоторые преимущества данного решения будут:

•Влияние на текущие бизнес процессы минимальный, так как компания продолжает работать с имеющемся решением

•Расходы по внедрению значительно ниже

•Уровень всех потенциальных проблем снижается по причине уменьшения масштаба влияния

•При провале проекта, отдел продаж продолжит работать с имеющейся системой

•Нет необходимости в миграции данных


Но возникают вопросы: Есть ли необходимость технической интеграции двух систем между собой и если да, то как и на каком уровне. Преимущества выбора Функционально Ориентированной Информационной Системы:

•Содержит необходимый функционал для обеспечения работы

•Обычно более проста и понятна для внедрения и использования

•Процесс внедрения проще за счет меньшего масштаба внедрения


Недостатки:

•Сопровождение потенциально большего количества информационных систем

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

•Требует большего распыления ИТ ресурсов

•Требования по знанию различных систем

Процесс Ориентированная Информационная Система

Теперь рассмотрим особенности Процесс ориентированного подхода к управлению организацией, и его влияние на построении ИТ инфраструктуры компании. Информационная система предприятия выбирается исходя из анализа бизнес процессов, происходящих в компании. Как написано в предыдущей главе, компания описывает бизнес процессы как основные, так и вспомогательные. Полнота описания процессов и их точность позволит выбрать наиболее правильное решение. Так для примера, была выбрана система «Microsoft Dynamics Navision» или 1С Конфигурация Управление Предприятием» покрывающая требования всех имеющихся бизнес процессов. Также в процессе роста организации могут возникнуть потребности в новом функционале, и требовании интеграции имеющегося решения с новой системой.

Преимущества выбора Процесс Ориентированной Информационной Системы:

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

•Сопровождение меньшего количества информационных систем (потенциально единая система в организации)

•Вопрос по интеграции информационных систем между собой не актуален или не критичный

•Не требует распыления ИТ ресурсов

•Нет требований по знанию большого количества различных систем


Недостатки:

•Более высокая первоначальная стоимость решения за счет большего функционала

•Риски внедрения и сопровождения выше, так как является основной для бизнеса, относительно сложной и т п

«Эталонная» Информационная Система (Management Information System)

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

•Единая Универсальная Информационная Система, построенная по модульному принципу, совмещающая в себе как функциональный, так и процессный подходы.


Преимущества Единой Информационной Системы:

•Все преимущества Процесс Ориентированной Информационной Системы

•За счет модульности, первоначальная стоимость внедрения и последующее сопровождение значительно дешевле

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

•Снижаются риски при внедрении и сопровождении нового функционала

•Единая информационная система от одного производителя более надежна, безопаснее и управляема


Все хорошо, ясно и понятно, руководитель компании вызывает к себе, ставит задачу найти «самое-самое» решение. Ищем, внедряем и спим спокойно дорогой товарищ. Но как говорится «… если хотите получить чудо – нанимайте сказочников…». На практике, любое более-менее среднее или тем более большое предприятие с более или менее тесной интеграцией с ИТ имеет в своем «зоопарке» два и более ИТ бизнес решения. Это связано с тем, что в каждой бизнес сфере (финансовая сфера, банках, страховых компаниях, строительстве, сельском хозяйстве и т п) имеется своя особенность ведения бизнеса. Кроме этого для международных компаний требования законодательства для одних и тех же функциональных подразделений может различаться кардинально. Адаптация или переделка «универсального» решения может быть очень трудоемким, затратным и провальным проектом. Не изобретайте велосипед заново там, где в этом нет особой необходимости.

Модели Интеграции Информационных Систем

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

•«Точка – точка» (Point-to-point) наиболее простая модель, использует прямое соединение систем между собой

•«ХАБ» (Hub & Spoke) представляется в виде центрального элемента, соединенного с различными системами

•«ЛЕС» (Spaghetti) – модель соединения всех систем со всеми

•«Интеграционная Шина Предприятия» (Enterprise Service Bus) общая «шина» данных для интеграции систем между собой, представляет из себя как правило самостоятельную систему.


Диаграмма Модели интеграции типа «Point-to-point» и «Hub & Spoke»


Диаграмма Модели интеграции типа «Spaghetti»


Диаграмма Модели интеграции типа «Enterprise Service Bus»


Далее компоненты систем интеграции можно разделить на следующие элементы:

•Периферийные системы (Front-end) – решения специфической операционной деятельности, или требует установку локально для взаимодействия с различными аппаратными решениями на местах (станки, кассовые аппараты и т п)

•Механизм интеграции данных (Integration) – механизмы интеграции данных

•Ключевые системы (Back-end) – конечные системы, решение консолидации и обработки данных

•Системы консолидации (OLAP & BI) – решение консолидированной аналитики и отчетов


Типы направлений интеграции потоков данных:

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

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

Комплексная Интеграции Информационных Систем Предприятия

Принимая во внимание общую концепцию построения Системы Управления Бизнесом (Management Information System), вопросы интеграции различных Информационных Систем между собой является неизбежным «злом». Задача ИТ знать об этом и быть готовым снизить риски и негативное влияние на бизнес и ИТ Архитектуру Предприятия. При построении комплексной интеграции предприятия необходимо принять во внимание структуру организации. Модель интеграции Информационных Систем полностью зависит от структуры организации. Интеграция ИС Предприятия может происходить на различных уровнях:


Интеграция различных информационных систем на организационном уровне:

•в пределах одной компании

•в пределах портфеля

•в пределах холдинга


Интеграция различных информационных систем на уровне бизнеса деятельности:

•По функциям (департаментам),

•По процессам

•По сфере деятельности


Интеграция различных информационных систем на технологическом уровне:

•инфраструктуры,

•платформы

•приложений

•базы данных

•данных


Степень Интеграция различных информационных систем:

•Частичная или Полная

•Ручная или автоматизированная

•Одно направленная или двух направленная


Рассмотрим более детально различные варианты интеграции с применением различных механизмов и типов.

Вариант 1: Интеграция двух информационных систем в масштабе одной компании

В качестве периферийной информационной системы выступает Автоматизированная Банковская Система (ABS), в качестве конечной системы программа ведения бухгалтерского учета (ACCOUNTING). Интеграции «одно направленного» типа с использованием механизма «Точка-точка» на уровне «Приложения» осуществляется от источника «ABS» к получателю «ACCOUNTING».




Все основные бизнес процессы происходят в АБС (создание клиентов, выдача кредита, все виды наличных оплат, в том числе и не банковского назначения, поступления переводов по погашению кредитов и т п). Транзакции из АБС выгружаются один раз при операции закрытии дня (Close of Business).

Бухгалтерская система обеспечивает ведение хозяйственных операций, бухгалтерского и налогового учета (амортизация, учет основных средств, безналичные переводы, не связанные с клиентами и т п).

Как пример пересекающихся процессов: новый поставщик вводится в АБС как потенциальный клиент, там же проводятся кассовые операции и т п. Регистрация товара от поставщика производится в системе «Бухгалтерии» и т п. Какие таблицы, поля, атрибуты должны быть переданы разбираются детально.

Подход к интеграции должен выполнятся ТОЛЬКО С ПРИМЕНЕНИЕМ ПРОЦЕССНОГО ПОДХОДА!!!

Вариант 2: Интеграция двух информационных систем в масштабе одной компании

В качестве периферийной информационной системы выступает Автоматизированная Банковская Система (ABS), в качестве конечной системы программа ведения бухгалтерского учета (ACCOUNTING).




Интеграции «двух направленного» типа с использованием механизма «Точка-точка» на уровне «Приложения» осуществляется между «ABS» и «ACCOUNTING».

Все основные бизнес процессы происходят в АБС (создание клиентов, выдача кредита, все виды наличных оплат, в том числе и не банковского назначения, поступления переводов по погашению кредитов и т п). Транзакции из АБС выгружаются один раз при операции закрытии дня (Close of Business).

Бухгалтерская система обеспечивает ведение хозяйственных операций, бухгалтерского и налогового учета (амортизация, учет основных средств, безналичные переводы), без ограничения.

Как пример пересекающихся процессов: новый поставщик вводится в «Бухгалтерии», там же проводятся кассовые операции и т п. Регистрация товара от поставщика производится там же и т п. Данные по новому клиенту пересылаются в систему АБС.

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

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

Вариант 3: Интеграция информационных систем различных компаний, объединённых в портфель или холдинг

Каждая компания имеет собственное ERP решение. Задача ИТ обеспечить сбор данных с различных систем в холдинг для последующего анализа и формирования отчетов для руководства. Для этого в холдинге развернута система OLAP & BI и система хранения данных (Data Warehouse DWH). Для обеспечения интеграции данных будет использоваться решение ESB «шина».




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

•относительная простота внедрения и сопровождения

•не высокая стоимость решения

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

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


К недостаткам решения можно отнести следующие:

•Система обладает только возможностями создания отчетов и аналитики.

•Точность и достоверность информации зависит от ввода данных на местах.

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

Вариант 4: Интеграция информационных систем различных компаний, объединённых в портфель или холдинг

Рассмотрим теперь интеграцию информационных систем различных компаний, объединённых в портфель или холдинг.




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

В первой компании (самая верхняя), текущая система управления не позволяет реализовать требования холдинга. В этом случае, компания использует решение «PRC» у себя в компании. Преимущества – единое решение, простота внедрения. К недостаткам можно отнести то, что данные в системе «PRC» не как не связаны с внутренней системой ERP компании.

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

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

Интеграции Информационных Систем Предприятия и централизация ИТ

Вопросы интеграции можно рассматривать в разрезе централизованного управления и предоставления ИТ сервисов. Далее на картинках представлены следующие три варианта предоставления сервисов и их интеграция в рамках холдинга:

Инфраструктура как Сервис (IaaS)

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


IaaS


Процесс может происходить с минимальными рисками воздействия на информационные системы компаний. Данная модель подходит для начального этапа централизации ИТ или же для уровня холдинга, с различными направления деятельности, когда информационные системы кардинально различаются по своей функциональности (например, Автоматизированная Банковская Система АБС, система Управления Сельскохозяйственным Предприятием УСХП, Система управления отелями и ресторанами и т п). Результаты можно увидеть непосредственно после интеграции.

Платформа как Сервис (PaaS)

Холдинг предоставляет инфраструктуру дата центра для размещения ИТ систем компаний в нем. В качестве бизнес системы выбирается единая платформа приложения. Все предприятия используют единую платформу в рамках портфеля или группы компаний, объединённых схожей деятельностью (сельское хозяйство, производство, строительство и т п). При этом у каждой компании имеется собственная база данных и конфигурация. Преимущества данного решения – помимо всех преимуществ IaaS, данное решение позволяет упростить внедрение и сопровождение систем, благодаря тому, что имеется одна платформа приложения, что удобно как для ИТ персонала, так и для сотрудников организации (обучение одной системе). Возможность получения сводных отчетов (отчеты нескольких компаний портфеля). Вопрос интеграции данных упрощается за счет унификации платформы. При этом каждая компания сохраняет свою идентичность и автономность, так как конфигурация и данные каждой компании хранятся в собственной базе. Данная модель подходит для второго этапа централизации ИТ или же для уровня портфеля, группы компаний, имеющие схожие направления деятельности, или же внедряются общие функции для всех компаний холдинга или группы компаний. Для выполнения данного этапа крайне важно ответить на два вопроса: первый – в чем цель и конечный результат, и второй – иметь четкую диаграмму всех бизнес процессов организации в целом, и компаний в частности. Для реализации данного плана, необходима заинтересованность руководства холдинга, поддержка руководства на местах, и тесная интеграция специалистов бизнеса и ИТ, хорошо разбирающихся в деталях процессов, происходящих в компании. Переход на унифицированную платформу, может потребовать дополнительные финансовые инвестиции, возможно значительные, и временные рамки, как для анализа, так и для поэтапного внедрения. Не стоит ожидать быстрые результаты и победы.


PaaS


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

Программа как Сервис (SaaS)

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


SaaS


Данные каждой компании хранятся в единой информационной системе холдинга. Преимущества данного решения – помимо всех преимуществ IaaS и PaaS предоставляет единую информационную систему холдинга. Каждая компания является частью холдинга. Информация по справочникам, номенклатуре, плану счетов унифицирована имеется возможность формирования консолидированных (суммированных по статьям) отчетов. Возможность интерактивного воздействия в процесс управления (авторизация и т п) со стороны руководства портфеля или холдинга. Данная модель подходит для финального этапа централизации ИТ. Как и для предыдущей модели, крайне важно ответить на два вопроса: первый – в чем цель и конечный результат, и второй – иметь четкую диаграмму всех бизнес процессов организации в целом, и компаний в частности. Для реализации данного плана, необходима заинтересованность руководства холдинга, поддержка руководства на местах, и тесная интеграция специалистов бизнеса и ИТ, хорошо разбирающихся в деталях процессов, происходящих в компании. Переход на унифицированную платформу, может потребовать значительные финансовые инвестиции и временные рамки, как для анализа, так и для поэтапного внедрения. Результаты интеграции будут видны только в долгосрочной перспективе. Данный этап характерен высоким риском в процессе интеграции. Кроме этого, процесс вывода компании из состава организации или холдинга может быть так же достаточно сложным и болезненным. Процесс доработки функционала для каждой компании, общий для всех компаний.

Проблемы выбора ИТ-решения для Бизнеса

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


Так при выборе Информационной Системы сугубо технического направления (защита периметра, системы Антивирусной защиты и т п) или общего назначения (Сервис предоставления файлов в совместное использование, системы почтовых сообщений и т п), выбор решения фактически полностью зависит от технических специалистов в области ИТ или Информационной Безопасности. Они говорят на одном «языке»; разбираются в особенностях решений, требованиям предъявляемых к системам и т п. Взаимодействие с бизнесом минимальное. Бизнес требования со стороны бизнеса могут быть сформулированы одним предложением: «… чтобы можно было посылать и принимать почту…». Как видно из рисунка, «вершина айсберга» – бизнес требования видны сотрудникам организации лишь часть общих требований к системе.

Вся суть коммуникации между бизнесом и ИТ сводится на пример к запросу, как слышит бизнес: «… дайте деньги на память…», что на языке ИТ сотрудников значит: «… Выделите финансирование на закупку модулей оперативной памяти для серверов…».




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




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

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

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

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

С другой стороны, выбор бизнес решений производится зачастую узким кругом руководителей без привлечения ИТ, что часто приводит к выбору по принципу: «… давайте возьмём как у той компании, если у них работает, то и у нас тоже будет…», или «… давайте возьмём самое дорогое решение – оно, наверное, самое лучшее…», или что еще хуже преследуя какие-то свои скрытые цели.

Рекомендации по выбору Информационной Системы Управления

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

Критерии выбора ИТ решения

В качестве основных критериев выбора решения, можно определить следующие:

Какие цели?

Какие процессы необходимо контролировать?

Размер организации: (Small Business, Medium Business, Large Business)

Заявленные возможности продукта или решения.

Удовлетворяют ли заявленные возможности требованиям бизнеса?

Техническая Архитектура:

•Архитектура решения: (client-server, Client-Application Server-Database Server)

•Серверная платформа: (Cloud based, Windows, Linux, Others)

•Варианты установки: (Cloud based или On-premises)

•Поддержка виртуализации: (Physical only, Hyper-V, VMware, Others)

•Поддерживаемые базы данных: (Microsoft SQL, MySQL, Internal DB)


На стороне клиента:

•Поддерживаемые устройства на клиенте: (Windows, Linux, Android, Mac OS, iPhone/iPad, Web-based)

•Поддерживаемые языки интерфейса: (Single English, Multi-Languages, Customer)


Архитектура отказоустойчивости и доступности

Архитектура восстановления и архивирования

Возможности масштабирование решения

Как данное решение вписывается в общую ИТ архитектуру.

«Купить или сделать?» В зависимости от способа приобретения ИС показатели эффективности, в первую очередь финансовые, будут отличаться. К тому же каждый раз набор вариантов дополняет самостоятельная разработка ИС, которую также необходимо оценивать.

Оценка производителей и поставщиков решений (Рейтинг, Наличие локального партнера (продажа / поддержка)

Модель внедрения:

•Стоимость: (Free (Open-Source), One-time payment, Monthly payment, Annual subscription, Perpetual)

•Лицензирование: (Per servers, Per hosts, Per operators/agents, Per modules, Per users, Per CPU/core, Per modules)

•Варианты подписки и версий


Модель сопровождения: (Technical support, Update support)

•Стоимость: (Free, Annual fee, Basic Technical support, Local support, Remote support)

•Лицензирование

•Возможности по обновлению продукта: (Update patches, Upgrade packs, Re-installation)


Возможности интеграции: с имеющимися решениями, с потенциально возможными решениями


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

•Организация покупает недорогое, быстро внедряемое решение с набором базового функционала, для использования в течении года или двух. Цель – сформировать рабочие бизнес процессы, обучение персонала.

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

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

Этапы выбора ИТ решения

Можно определить следующий порядок действий по ИТ проекту.

На первом этапе:

•Сбор требований со стороны бизнеса – инициатора проекта (бизнес требования)

•Добавление технических требований со стороны департамента Безопасности

•Добавление технических требований со стороны ИТ департамента


На втором этапе:

•Поиск решений, без ограничений по стоимости, архитектуре и т п.

•Сбор заявленных возможностей решения


На третьем этапе:

•Анализ решений (со стороны бизнеса) на соответствие бизнес требованиям

•Анализ решений (со стороны ИТ департамента) на соответствие требованиям, архитектуре и т п

•Формирование «короткого» списка решений удовлетворяющих всем требованиям. При необходимости проводится обращение к департаменту Снабжения для получения предложений


На четвертом этапе:

•Детальный анализ решения, выбор архитектуры, производителя, определение бюджета и т п

•Принятие решения по бюджету, срокам (со стороны бизнеса)

•Формирование технического задания для проведения тендера

•Формирование плана внедрения (частичное, полное и т п)

•Выбор «короткого» списка победителей

•Уточнение последних изменений и дополнений

•Финальный тендер (по необходимости) для «короткого» списка компаний


На пятом этапе:

•Закупка

•Подготовка к внедрению

•Внедрение

•Корректировка

•Сопровождение

•Обновление и улучшение

•Вывод из эксплуатации

Метод Покупки Готового Решение (COST или «OFF-the-SHELF»)

COST или («OFF-the-SHELF» коробочное готовое решение) – Одним из подходов является покупка готовых решений. При покупке такого программного обеспечения организация должна:

•понимать достоинства и недостатки этого подхода;

•формализовать процесс выбора наиболее эффективного готового решения;

•определить процесс для эффективной интеграции и настройки готового решения;

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

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

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

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


При покупке решения остается необходимость в:

•кастомизации (customization) – адаптация продукта под требования клиента, первоначальное конфигурирование, настройка интерфейса, изменение бизнес процессов и т п,

•локализация (localization) – язык интерфейса, перевод печатных форм и т п.


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

К недостаткам можно отнести – менее гибка, чем разработка собственных решений.