Реорганизация бизнес - процессов
При изменении информационной системы
В крупной организации.
Содержание:
1. Концепция информационной системы и требования которые могут к ней предъявляться
2. Типы изменений информационной системы
3. Принципы планирования проекта по изменению информационной системы
4. Принципы формирования и работы команды, отвечающей за изменение информационной системы, подбор ее участников и взаимоотношения с организацией
1. Концепция информационной системы и требования которые могут к ней предъявляться
В настоящее время понятие информационной системы настолько размыто, что под информационной системой может быть определено любое понятие от компьютерной программы, помогающей автоматизировать какой-то процесс, до сложивщегося набора правил и процедур, регламентирующих действия сотрудников компании по организации процессов создания и использования информации в нужном для компании виде.
Поэтому не ставя перед собой задачу рассмотреть все возможные определения для информационной системы, автор предложил бы1 понимать под информационной системой интегрированную базу данных, позволяющую благодаря своей функциональности обрабатывать широкий спектр бизнес процессов, в который могут входить следующие (поскольку данная работа связана с участием автора в конкретном проекте по интеграции новой информационной системы в крупной компании, определенные области деятельности организации могли не войти в данный список, как например кадровый учет, некоторые финансовые, бухгалтерские и логистические аспекты, маркетинг и т.д.):
· процесс приема заказов
· учет складского инвентаря
· учет транспортировок продукции
· процесс закупок продукции
· процесс таможенной очистки продукции
· бухгалтерское отражение всех указанных процессов
· учет счетов к получению
· учет счетов к выплате
· учет затрат и т.д.
__________________
1Поскольку выбор данной темы был обусловлен участием автора в проекте, во многом отражающем тенденции по изменению информационных систем в крупных компаниях, автор счел возможным рассматривать процесс перехода крупных компаний к новой интегрированной базе данных с широкой функциональностью во многом типичным, а следовательно и саму базу данных (постепенно завоевывающую рынок «крупных» информационных систем) типичной и наиболее подходящей под определение информационной системы.
Что касается функциональности информационной системы, то признаком «системности» автор предложил бы считать степень разработанности данной функциональности. Чем больше областей деятельности организации охватывает данная конкретная база данных, и чем больше функциональных возможностей по учету нестандартных «жизненных ситуаций» эта база данных предоставляет, тем ближе ее можно отнести к информационной системе. Естественно информационная система должна быть способна обрабатывать достаточные объемы информации (определяемые размером бизнеса конкретной организации) за относительно короткое время.
Под «интегрированностью» информационной системы можно понимать степень связанности всех процессов организации, которые нашли отражение в системе, в единое целое. Типичным примером интегрированной системы может быть система, которая позволяет учитывать и логистические, и бухгалтерские процессы. Например, при оформлении в системе заказа, который делает заказчик, в системе возникает соответствующая бухгалтерская проводка, увеличиваются счета к получению и уменьшается количество товара на складе, которое имеет статус свободного использования.
Предложив понимать под информационной системой описанное выше и ограничиваясь перечислением факторов, свойственных информационной системе, автор дал бы неполное представление о ней. Одной из важнейших компонент, непосредственно связанных с информационными системами, являются люди, использующие систему в своих целях, и процессы, регламентирующие деятельность сотрудников по использованию системы. Организация данных процессов и обучение сотрудников работе с системой являются ключевой предпосылкой успешного функционирования системы и будут описаны ниже при описании изменения информационной системы.
Планирование в процессе осуществления проекта.
Приведенная ниже схема показывает обобщенный принцип планирования проекта. Из одной из деталей данной схемы является то, что планирование в процессе проекта представляет собой непрерывный процесс, который длится до завершения проекта. Это связано со сложностью разработки идеального плана, в котором будут предвидены все детали и возможные изменения субъективного (связанного с самим проектом) и объективного (связанного с внешними источниками) характера.
Рис. 3.1. Планирование проекта по изменению информационной системы.
При малейших переменах (например, когда обнаруживается, что система позволяет внедрить новый процесс с большой легкостью или когда кто-то из важных участников проекта по какой-либо причине на время выбывает из проекта) возникает необходимость корректировки поставленных планов и времени их реализации. Соответственно типы изменений в планах можно позиционировать на матрице “сроки проекта - содержание проекта”.
| Сроки меняются | проекта не меняются | |
| меняется Содержание | 1. Часть функциональности системы добавлена, что вызывает увеличение сроков 2. Часть функциональности системы удалена, что вызывает сокращение сроков | Часть функциональности системы добавлена или удалена, но проект выполняется в соответствии с планом |
| проекта не меняется | 1. Проект не может быть завершен в поставленные сроки в силу определенных причин 2. Проект может быть завершен раньше установленных сроков в силу определенных причин | Изменений не происходит, проект развивается в строгом соответствии с планом |
Рис. 3.2. “Сроки проекта - содержание проекта”
Опыт показывает, что чаще всего меняются сроки завершения проекта, причем в основном в сторону увеличения. Это происходит из-за того, что в успешных организациях при планировании ставятся агрессивные цели для того, чтобы вдохновить сотрудников на более продуктивную работу. Поэтому когда происходят изменения в процессе осуществления проекта (а они как правило происходят в каждом серьезном проекте) возникает необходимость задействования дополнительных ресурсов, в том числе и времени. Если кроме времени возможно дополнительное использование такого ресурса, как набор функций, то меняется и содержание проекта. С другой стороны, дополнительное использование других ресурсов (стоимости и людей) уменьшает необходимость увеличения времени, то есть сокращает сроки выполнения проекта.
Планирование в процессе осуществления проекта происходит на каждой стадии проекта на регулярной основе. Более того, по мере продвижения проекта по каждой из стадий часто целесообразно организовывать собрания основных участников проекта для определения текущего положения дел и сравнения с планом. Регулярность таких собраний зависит от длительности проекта и его масштаба. Если между текущим положением дел и планом намечается разница, то в первую очередь производится анализ способов устранения отставания, а при невозможности устранить отставание изменяется план проекта, что согласовывается с топ менеджментом на регулярных собраниях (см. ниже).
При переходе с одной стадии на другую составляется детальный план реализации новой стадии проекта в соответствии с изменениями в планах, если такие имеются.
Описание бизнес процессов.
Для того, чтобы иметь четкое представление о том, какие конкретно процессы будут подвергаться изменениям и каким образом при изменении информационной системы, нужно иметь четкое формальное описание существующих процессов. Детальность такого описания должна быть на уровне концепции процесса и основных его составляющих, а также входящих и выходящих ресурсов. Например, если это процесс обработки заказов, то нужно создать общее описание процесса (с чего начинается, из чего состоит и чем заканчивается, в какое время происходит какая стадия этого процесса, какие параметры существуют у заказов, например условия оплаты, классы заказчиков, категории услуг и продуктов, с каких складов осуществляются отгрузки и т.д.). Пример такой схемы приведен в Приложении 1 (Прием заказа). При описании бизнес процессов может оказаться полезным создание схем, потому что они наглядно показывают основные составляющие процесса.
Описание бизнес процессов является не только базой, по отношению к которой будет меняться процесс, но также описание процессов является неким механизмом оценки возможных изменений и критерием, которому должна соответствовать новая схема измененного бизнес - процесса.
Описание бизнес - процессов осуществляется в самом начале проекта, а результат этой стадии - наличие свежего сборника документации по процессам организации - является той информационной базой, с помощью которой формируется содержание изменений в ходе проекта.
Необходимые доработки.
В случае, когда обнаруживается, что система не позволяет осуществлять какой-нибудь важный процесс (или в системе не существует необходимого приемлемого набора отчетности), формируются запросы на разработку дополнительной функциональности.
Разработка может осуществляться как внешними специалистами, так и внутренними. Данная стадия происходит как правило в параллели с предыдущей и иногда даже с последующей (например, когда доработки не носят существенного характера и не могут помешать обучению пользователей и дальнейшему тестированию системы).
На данной стадии может измениться содержание проекта, причем как в сторону сокращения части внедряемой функциональности, так и в сторону ее расширения, которое во многом это также зависит от бюджета проекта.
Ввод реальных данных.
После того, как все необходимые детали по работе системы согласованы с пользователями, система признается готовой к установке, а топ менеджмент принимает окончательное решение о внедрении (так называемое “go-no-go solution”), начинается сам переход с одной системы на другую.
Этот переход начинается с ввода реальных данных в новую систему. Опыт показывает, что наиболее эффективным является начало ввода данных в параллели с вводом в старую систему (хотя возможен и вариант резкого перехода, но его рекомендуется проводить только когда переход на новую систему не представляет особой сложности, является стандартным хорошо изученным решением, с успехом применяемым ранее). Это требует дополнительного напряжения со стороны пользователей, потому что в течение какого-то времени ( день, неделя или даже больше) им придется работать в двух системах одновременно вместо одной. Привлекать людей со стороны не рекомендуется, потому что это дорого, для этих людей нужно провести хороший тренинг (несмотря на который вероятность ошибок все равно велика), что занимает время, которого в конце проекта становится катастрофически мало.
Ввод данных (все системные настройки должны быть уже введены в систему на стадии тестирования системы пользователями) начинается с ввода так называемых мастер - данных:
заказчики, их адреса, контактные лица и т.д.;
список продуктов с необходимыми характеристиками, такими, как количество штук в коробке, размеры, вес, коды и т.д.;
цены и скидки - как на продукты (закупочные и продажные), так и на другие услуги (перевозки, консультации, денежные переводы и т.д.);
склады, их адреса, контактные лица и т.д.;
поставщики, их адреса, контактные лица и т.д.;
другие партнеры (перевозчики, консультанты, банки и т.д.);
транспорт, характеристики машин (объем, тип, номера и т.д.);
другое.
Затем начиная с определенного момента, когда все базовые данные введены, в систему начинает вводиться рабочая информация, соответствующая бизнес - процессам.
Это начинается с ввода начальных балансов (количества продукции на складах, счета к оплате и счета к получению, кредитный статус заказчиков, открытые заказы и т.д.), как правило в выходные дни. Потом начиная со следующего рабочего дня начинается параллельный ввод данных в две системы - новую и старую.
Параллельный ввод данных длится до тех пор, пока в новую систему не поступит вся необходимая информация для начала самостоятельной (то есть без помощи данных в старой системе) работы - например, когда все не отгруженные заказы, которые существовали в старой системе, были или введены в новую, или отгружены в старой системе и попали в архив.
Переход на новую систему.
Переход на новую систему означает прекращение ввода данных в старую систему и начало (продолжение, если переход был плавным, как это было описано выше) ввода данных только в новую систему.
Прием заказа .
Прием заказа:
Заказ принимается по:
Электронной почте
Факсу
Телефону
Типы заказов: 22 паллетные, 33 паллетные а/м, ж/д вагоны или контейнеры
Типы транспортировки:
Доставка транспортом компании
Самовывоз
При необходимости корректировки заказа - оператор звонит заказчику и согласовывает изменения в заказе
Ввод заказа в систему:
Заказ (заголовок):
Покупатель
Номер заказа
Требуемая дата доставки
Дата обработки заказа
Дата действия прейскуранта
Заказ (строчки):
Код товара
Кол-во коробок
Единица измерения (коробка)
Заказ трансформируется в Поставку:
Поставка (заголовок):
Получатель
№ поставки
Вес поставки
Дата отгрузки (предлагается системой)
Поставка (строчки):
Код товара
Кол-во коробок
Единица измерения (коробка)
Кредитный контроль (разрешение/ блокировка/ изменение заказа) и проверка на наличие товара (товар есть/ товара нет ® изменение заказа) осуществляются системой
Сравнение заказа и измененного заказа: генерирование отчета об отказах
Окончательное согласование заказа при необходимости:
Изменения согласовываются по телефону
Оператор подтверждает заказ
Заказчику сообщается номер заказа и сумма к оплате
Транспортная группа согласовывает доставку товара
Отчет о заказах к отгрузке
Заказ на перевозку
Ввод транспортных данных в систему
Распечатка заказа
Формирование подборки заказа в системе для склада:
Заголовок:
Получатель
№ поставки
Дата отгрузки
Общий вес
Строчки:
Склад
Камера
Товар
Количество
Единица измерения (коробки)
Подобранное количество
Единица измерения (коробки)
Сохранение изменений
Разноска (пост)
Оформление и распечатка счета
Генерирование отчета об открытых заказах
Генерирование отчета о разрешенных заказах
Приложение 2. Выдержка из начального плана проекта.
Project Organisation
Project Sponsor
Person A F&A Manager Russia
Person B Logistics Manager Russia
Other Board Members
Person C IT Manager Russia
Steering Team
Person D
Person E
Person F
Person G
Project Manager
Person H IT Project Manager
Project Team
IT: Person I IT Analyst
Person J IT Analyst
F&A: Person K F&A Clerk
Logistics: Person L Logistics Project Manager
Logistics: Person M Logistics Project Assistant
Warehouse: Person N Warehouse Manager
Local Resources
Logistics: Person O Logistics Development Manager
Person P OSB Manager
Person Q Moscow Distribution Manager
Person R Deployment Manager
Person S Moscow WH&Transport Manager
Person T Supply Planning Manager
Person U Customs Manager
Warehouses: Person V Warehouse “A”
Person W Warehouse “B”
Person X Warehouse “C”
F&A: Person Y Accounting Manager
Person Z GL Supervisor
Person AA Banking Manager
Person AB Profit Forecaster
IT: Person AC Corporate Support Services Manager (I&TS)
Person AD Warehouse Systems Engineer
Person AE Finance Systems Analyst
Person AF Finance Systems Analyst
Person AG System Administrator
External Resources
SAP R/3 RSG
EMEA Implementation Support Team
SAP Consult C.I.S.
Stakeholders
F&A analysis
Sales Department
Marketing Department
Platinum RSG
Key Roles and Responsibilities:
Project Board:
Allocate and make funds and resources available;
Communicate to Project Manager all environmental and business changes that impact the project;
Confirm business and technical requirements;
Confirm assumptions;
Resolve key issues as identified;
Review and approve overall project plan and schedules;
Manage effort against priorities;
Review progress and communicate to business partners and appropriate MSD people;
Review and authorize project exception plans, if applicable;
Meets monthly (or as issues arise) to review project progress.
Project Manager:
Develop and manage overall critical path schedule for the effort;
Coordinate the effort of people and develop roles/expectations for people working on the team;
Identify and obtain required resources;
Insure proper approvals for business and technical solutions;
Resolve or escalate issues to Project Board and/or Steering Team as needed;
Communicate the impact on the Stakeholders;
Interfaces with other key MS projects impacting SAP R/3 project and ensure compatibility;
Host and work with RSG resources;
Meets monthly (or as issues arise) with Project Board to report project progress;
Meet with team be-weekly (or as issues arise) and prepare meeting notes;
Be trained on FI, CO, SD and MM modules.
Business Team Members:
Formalize business requirements of their organizations;
Together with PM and MS TMs develop compromise business solutions in case of conflicting business requirements;
Ensure the implementation of changes in business process is properly communicated to their organizations;
Coordinate business testing and Quality Assurance in their organizations;
Recommend resources from their organizations for each stage;
Escalate issues to Project Manager as needed;
Be trained on FI, CO, SD and MM modules.
MS Team Members:
By help of Business TMs map business processes into system in a way that ensures feasibility of technical realization;
Provide technical solutions;
Ensure compliance with global standards;
Initiate the development/approval of alternative business solution if the initial one is not technically feasible;
Escalate issues to Project Manager as needed;
Be trained on FI, CO, SD and MM modules.
Key Business Resources:
Present business requirements for their organization to the project;
Liaise and reconcile business requirements with Key Business Resources from other organizations;
Assist in the collective prioritization of business requirements;
Review the major deliverables of the project;
Communicate plans, progress, status, expectations, etc. for the project back to their organizations;
Inform PM about their unavailability.
Key MS Resources:
Will be involved in order to ensure smooth transition from Platinum to SAP and engaged in some specific tasks
Реорганизация бизнес - процессов
Дата: 2019-07-31, просмотров: 195.
