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

Developing the support business-processes information system for self-regulation institute

Авторы

Кравченко Анатолий Васильевич
канд. техн. наук
Россия, Новосибирский государственный технический университет
Некрасова Оксана Михайловна
Магистрант
Россия, Новосибирский государственный технический университет

Аннотация

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

Ключевые слова

Саморегулирование (СРО), некоммерческое партнерство (НП). структурная модель, онтологическая модель, объектно-ориентированная модель, информационная система, бизнес-процесс, информатизация, формализация, оптимизация.

Моделирование бизнес-процессов | Naked BPM

Рекомендуемая ссылка

Кравченко Анатолий Васильевич, Некрасова Оксана Михайловна. Разработка информационной системы поддержки бизнес-процессов института саморегулирования // Современные технологии управления. ISSN 2226-9339. — №11 (11). Номер статьи: 1103. 11.2011. Режим доступа: https://sovman.ru/article/1103/

Authors

Kravchenko Anatoly Vasilevich
Cand.Tech.Sci.
Russia, Novosibirsk State Technical University (NSTU)
Nekrasova Oxana Mixailovna
Russia, Novosibirsk State Technical University (NSTU)

Abstract

Studying the methods of sructurization, optimization and the automation for modern self-regulation institute business-processes are considered in the article. The aim of the text is to show the strategy of modeling self-regulation information system and the strategy of the membership dues accounting and agency compensation.

Keywords

Self-regulation (SRO), noncommercial partnership (NP). Structural model, the ontologic model, object-oriented model, information system, business-process, information, formalization, optimization.

Suggested citation

Kravchenko Anatoly Vasilevich, Nekrasova Oxana Mixailovna. Developing the support business-processes information system for self-regulation institute // Modern Management Technology. ISSN 2226-9339. — №11 (11). Art. # 1103. Date issued: 08.11.2011. Available at: https://sovman.ru/article/1103/

Введение

Совершенствование системы государственного регулирования признается одним из важнейших направлений экономической политики в России. В рамках этой политики образовался инновационный институт саморегулирования [1].

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

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

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

Обоснование актуальности проблемы информатизации в саморегулировании

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

В результате деятельность СРО, стала напоминать неуправляемое, хаотичное движение информационного и документарного потоков, не подчиняющегося ни каким стандартам документооборота. Но для сектора «business-to-business», осуществляющего в основном контроль, учет и выдачу юридически значимых документов, наличие автоматизированного документооборота является критерием успеха. В связи с этим возникла острая потребность структуризации и автоматизации бизнес-процессов саморегулирования.

Методика разработки информационной системы СРО

В данной работе процесс информатизации рынка СРО предлагается рассмотреть на конкретном примере моделирования и автоматизации информационной системы представителя крупнейшей саморегулируемой организаций в Российской Федерации – НП СРО «Объединение». Ниже приведена краткая характеристика объекта автоматизации.

Представительство НП СРО «Объединение» занимается оформлением допусков на строительство, проектирование, изыскание, и осуществляет сотрудничество с Московским НП СРО «Объединение» на основании официального соглашения.

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

Процесс создания информационной системы для любого объекта делится на ряд этапов в соответствии с жизненным циклом ИС, это [3]:

• формирование требований к системе;
• проектирование ИС;
• реализация;
• тестирование;
• ввод в действие;
• эксплуатация и сопровождение.

Рисунок 1 — Схема взаимодействия с представителями и государственным контролирующим органом

Начальная стадия «Формирование требований к системе» начинается с предпроектного обследования.

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

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

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

Учитывая вышеперечисленные проблемы организации и постоянную потребность в «подстраивании системы на лету» с учетом изменений в законе, автором была предложена следующая структура построения ИС СРО (структура представлена с примерами из основных бизнес-процессов):

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

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

Рисунок 2 – Общая информационная модель процессов отдела СРО

Формирование диаграммы последовательностидля выделенного подпроцесса, пример диаграммы последовательности представлен на рисунке 3;

Рисунок 3 – Пример Диаграмма последовательности

Спецификация процесса, пример спецификации подпроцесса представлен в таблице 1.

Таблица 1 – Спецификация процесса «Привлечение клиентов»

• Прайс-лист на вступление
• Перечень требований на вступление

Формирование онтологической модели процесса, пример онтологической модели процесса представлен на рисунке 4;

Рисунок 4 – Онтологическая модель процесса «Привлечение клиентов»

Разработка объектно-ориентированнойER-модели, с учетом уже существующей, заполненной CRM-системы. ER-модель представлена на рисунке 5;

Рисунок 5 – Общая ЕR-модель отдела СРО

Внедрение ИС СРО включало такие этапы как:
1. Тестирование доработанного программного продукта;
2. Заполнение новых форм в дополнение к уже существующим;
3.Обучение персонала;
4. Поддержка работоспособности системы.

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

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

Рисунок 6 – Схематические принципы взаимодействия трех финансовых отделов

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

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

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

По той причине, что представительство не имеет доступа к «Клиент -Банку» головного СРО настройка собственной системы учета платежей является для него приоритетной задачей, а следовательно потребовалось изменить систему учета платежей LIFO на точечный учет платежей.

Таблица 2 – Метод разнесения платежей по принципу LIFO

Таблица 3 – Метод разнесения платежей для СРО

Данная проблема была решена с помощью изменения кода CRM системы, а именно было добавлено поле «Дата разнесения», позволяющее привязывать дату платежного поручения к дате оплаты, как показано на рисунке 7.

Рисунок 8 – Привязка даты оплаты к месяцу оплаты

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

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

Рисунок 8 – Вывод данных об оплатах членских взносов

2. После формирования единой базы платежей, возникает задача извлечения из нее данных для формирования отчетов (в соответствии с требованиями головного СРО) и контроля над уплатой членских взносов.

Поясним суть логики формирования отчетов для головного офиса в Москве:

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

1. В отчет для Москвы можно включать только платежи за текущий месяц и за предыдущие месяцы, оплаченные в этом месяце (эти месяцы должны попадать строго в период с 20.05.2010 по текущий месяц)

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

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

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

• Необходимо включить все платежи за период с 01.01.2010 — 31.06.2010.
• В отчет включаем платежи за сентябрь месяц, оплаченные в период (факт) с 20.05.2010 по 31.06.2010.
• Также в отчет включаем платежки за месяцы янв….август, оплаченные сентябрем (т.е. должны быть просмотрены все месяца заданного диапазона и выбраны в них платежи с датой 01.06.2010 по 31.06.2010).
• Платежи контрагента включаются в отчет только в том случае, если есть план и факт оплаты с даты выставления плана (план может быть выставлен раньше, чем задан период, например с 01.12.2009г.) по месяц и год заданного диапазона (с 01.01.2010-31.06.2010) не пустое множество.

В результате фильтрации, должен выводится отчет вида (см. таблицу 5 (данные в таблице условны)). Отчет должен выводиться в формат Microsoft World.

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

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

Таблица 5 – Отчет по ЧВ Москва

Наименование организации

ИНН организации

Номер первичного допуска

Дата допуска

Номер и дата платежного поручения

Вознаграждение поверенного, руб.

Месяц оплаты

1

2

3

4

5

6

7

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

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

Аннотация: рассматриваются базовые этапы внедрения корпоративных информационных систем. Кроме того выполняется обзор проектных документов каждого из этапов, а также демонстрируется зависимость данных заданной фазы на документы последующих этапов.
Скачать: PDF.
Ключевые слова:документы ERP систем, документирование внедрения корпоративных информационных систем, документирование информационных систем, документы в информационной системе, проектная документация ERP систем, рабочая документация ИС, техническая документация КИС, нормативные документы информационной системы, нормативные документы по проектированию информационных систем, документы внедрения ПО, документы внедрения информационных систем, этапы и документы внедрения программного продукта, опытная эксплуатация информационных систем, ГОСТ Р 54869-2011, ANSI PMBoK.

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

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

Цель и задачи

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

• обзор литературы, посвященной внедрению КИС;
• рассмотрение базовых этапов имплементации КИС;
• анализ проектных документов и их зависимостей от этапов.

1. Обзор подходов внедрения корпоративных информационных систем

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

Речь идет об отраслевых стандартах, в частности, ГОСТ Р 54869-2011 [1], а так же международном стандарте ISO 21500 [2]. Документы содержат описание этапов управления проектами от процесса инициализации до завершения вне зависимости от вида реализуемой системы. Поэтому возможно использование указанных стандартов для реализации технических, информационных и корпоративных систем. Свод профессиональных знаний по управлению проектами, представленный ANSI PMI PMBoK [3], регламентирует процессы планирования, исполнения, проверки и воздействия от этапа инициирования до завершения проекта. Аналогично ГОСТ Р 54869-2011 и ISO 21500 допускается его применение для управления внедрением различных видов систем.

Рис. 1.Основные подходы внедрения КИС

Рис. 2.Типовые этапы реализации проекта внедрения КИС

2. Проектные документы типовых этапов реализации проекта

В предыдущем разделе были выделены типовые этапы реализации проектов по внедрению КИС, включающие

• подготовку проекта;
• проектирование;
• реализацию;
• подготовку к опытно-промышленной эксплуатации (далее — ОПЭ);
• ОПЭ;
• переход к продуктивной эксплуатации (далее — ПЭ)

и являющиеся общими для методологий ASAP, ADM, MDSS и стандартов [1-3]. Допускается отсутствие этапа ОПЭ, тогда 4-я и 5-я фазы проекта будут обеспечивать подготовку к ПЭ и ПЭ соответственно. Рассмотрим документы каждого из этапов подробнее (рис.3).

Рис. 3.Типовые этапы внедрения корпоративных информационных систем с указанием выходных документов

2.1. Этап подготовки проекта

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

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

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

2.2. Этап проектирования

Требования заказчика сопоставляются со стандартным решением КИС (Fit-анализ) для выявления функционального дефицита (GAP-анализ). Функциональный дефицит требует доработки системы, для чего готовятся спецификации на разработку, содержащие постановку задачи и предлагаемый вектор решения. Разрабатывается концепция ролей и полномочий, определяющая перечень ролей пользователей и правила их создания и присвоения сотрудникам. Стандартный функционал КИС, спецификации на разработку и концепция ролей и полномочий необходимы для формирования проектных решений. Проектные решения содержат бизнес-процессы заказчика в моделях «как есть» и «как будет» [8-9] с указанием доработок системы и ролей пользователей.

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

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

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

2.3. Этап реализации

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

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

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

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

2.4. Этап подготовки к опытно-промышленной эксплуатации

Реализация системы выполнена, и журнал проблем содержит незначительное число замечаний. Начинается подготовка к ОПЭ. Первоочередной задачей данного этапа является обучение конечных пользователей. Готовятся инструкции конечных пользователей (в разрезе бизнес-процессов или операций).

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

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

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

2.5. Этап опытно-промышленной эксплуатации

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

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

2.6. Этап перехода к продуктивной эксплуатации

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

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

3. Зависимость подготавливаемых документов от этапов проекта

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

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

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

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

Результаты и выводы

Показана зависимость документов от фаз проекта. Проиллюстрировано, незначительное изменение одного документа требует актуализации документов, используемых для подготовки исходного (рис.4). Это в значительной степени увеличивает трудоемкость работ. Детальное описание типовых работ на каждой фазе проекта, проведение анализа проектной документации и выявление основных требований к содержанию документов аналогично [10] определяют перспективное направление дальнейших исследований.

Литература

1. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture’s Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Проектирование информационных систем: учебное пособие / Гвоздева Т.В., Баллод Б.А. – Ростов н/Д.: Феникс, 2009. – 508 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.208-228.
10. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.

Источник: stepanovd.com

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

Из материалов интервью с руководителем проектного офиса компании ITLand Семеном Иоффе Вы узнаете об интересных практиках и инструментах, которые помогают снизить сроки и стоимость проектов по внедрению информационных систем:

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

— Семен, расскажите, пожалуйста, чем занимается Ваша компания?

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

— Как Вы синхронизируете процессы, реализованные в функционале Ваших продуктов, и реальные процессы Заказчика? Используется при этом моделирование процессов? Например, на стадии подготовки ТЗ на внедрение?

ITLand выполнила много проектов, которые начинались с описания . Бывает, что описанные и технические требования мы получаем от Заказчика.

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

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

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

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

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

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

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

В случае если у Заказчика не формализованы, то до внедрения системы мы описываем . Для этого мы используем программное обеспечение Business Studio. Чаще всего мы описываем верхнего уровня, декомпозируя их на сценарии работы пользователей.

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

— Как сценарии используются в рамках внедрения?

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

Рис. 1. Пример сценария работы пользователей

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

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

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

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

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

Александр Трубецкой, директор филиала о реализованной базе знаний.

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

— Какие эффекты Вы отмечаете от использования сценариев работы пользователей при внедрении информационной системы?

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

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

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

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

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

— Откуда Вы черпаете успешные практики проектной деятельности? Или это по большей части собственные наработки?

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

Рис. 3.Монитор прогресса проекта

Рис. 4.Фазы проекта и ворота качества

Например, у одного из наших Заказчиков была потребность в визуализации структуры цены, совместно мы превратили его в методику, разработали формы отчетности И вот первую, техническую часть методики, мы добавили в функционал новых редакций 2.4 систем «1С:PM Управление проектами» и «1С:ERP+PM Управление проектной организацией 2».

Рис. 5.Визуализация структуры цены контракта в виде дерева показателей проекта

— Как Вы планируете развивать свою методику с учетом использования Business Studio?

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

ITLand— российский разработчик программного обеспечения и интегратор комплексных решений для управления заказами, проектами, ресурсами и финансами. На сегодняшний день продукты и решения ITLand используются более чем в 300 организациях России и СНГ- в проектных институтах, НИПИ, в инжиниринговых и нефтегазовых компаниях, девелоперских и строительных организациях, конструкторских бюро, на промышленных предприятиях.

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