Если Вы решили, что Вам необходим продукт бизнес-моделирования, то Вы встаете перед вопросом: "Какой из продуктов мне больше подойдет?" Мы попробуем помочь Вам в этом нелегком деле. При этом мы не предлагаем созданное нами же сравнение, результат которого известен заранее. К Вашему вниманию предлагается рассмотрение вопросов, связанных с выбором продукта, а так же заготовка таблицы сравнения программных продуктов по бизнес-моделированию.
Выбор системы бизнес-моделирования и требования ISO 9001:2000
Выбирая программный продукт для описания бизнес-процессов, предприятие производит сравнение различных продуктов. Согласно требованиям ISO 9001:2000 (п.7.4. Закупки) предприятие должно выполнять ряд действий при выборе продукта и поставщика. А именно:
Пункт стандарта
Текст стандарта
Что это означает
Как это реализуется если Вы выбрали Business Studio
7.4.1 Процесс закупок
Организация должна обеспечивать соответствие закупленной продукции установленным требованиям к закупкам. Тип и степень управления, применяемые по отношению к поставщику и закупленной продукции, должны зависеть от ее воздействия на последующие стадии жизненного цикла продукции или готовую продукцию.
Должны быть сформированы требования к закупаемой продукции и произведена оценка важности каждого критерия.
Организация должна оценивать и выбирать поставщиков на основе их способности поставлять продукцию в соответствии с требованиями организации. Должны быть разработаны критерии отбора, оценки и повторной оценки. Записи результатов оценивания и любых необходимых действий, вытекающих из оценки, должны поддерживаться в рабочем состоянии (4.2.4).
Должны быть установлены критерии не только продукта, но и самого поставщика продукта.
Процесс выбора поставщика должен документироваться.
Оценка поставщика должна производиться периодически.
Предлагаются критерии оценки по продукту в шаблоне сравнительной таблицы. В нашем случае повторная оценка не будет осуществляться.
7.4.2 Информация по закупкам
Информация по закупкам должна описывать заказанную продукцию, включая, где это необходимо:
а) требования к утверждению продукции, процедур, процессов и оборудования;
б) требования к квалификации персонала;
в) требования к системе менеджмента качества.
В случае необходимости Заказчик может выставить разработчику критерии по:
а) процессу разработки и тестированию продукта
б) требования к квалификации персонала, который участвует в разработке продукта
в) требования к системе управления организацией разработчика
а) тестирование продукта проводят собственными силами, с участием дилеров и некоторых клиентов. Система Business Studio прошла Microsoft Platform Test, подтверждающий совместимость программы с новейшими операционными системами Microsoft. Тестирование проводилось центром VeriTest. Дополнительная информация на сайте Microsoft.
б) Разработчик является Microsoft Certified Partner по компетенции - ISV/Software Solutions Разработка программного обеспечения.
7.4.2 Информация по закупкам
Организация должна обеспечивать адекватность установленных требований к закупкам до их сообщения поставщику.
Требования должны быть сформированы, не противоречить друг другу и только затем предъявлены поставщику.
Организация должна разработать и осуществлять контроль или другую деятельность, необходимую для обеспечения соответствия закупленной продукции установленным требованиям к закупкам.
Закупленная продукция должна проверяться на соответствия, заявленные поставщиком.
В нашем случае, специфика продукта такова, что такой постоянной проверки не требуется.
7.4.3 Верификация закупленной продукции
Если организация или ее потребитель предполагают осуществить верификацию на предприятии поставщика, то организация должна установить в информации по закупкам предполагаемые меры по проверке и порядок выпуска продукции у поставщика.
Проверка закупаемой продукции и процессов ее создающих, может осуществляться у поставщика. Для этого, поставщику должны быть сформированы требования и критерии проверки у него.
Все желающие могут лично познакомиться с разработчиками продукта в г.Самаре, ул. Ново-Садовая, 106, ТД "ЗАХАР", 7А этаж.
Основные виды деятельности разработчика: управленческий и ИТ-консалтинг, разработка ПО.
Краткая теория выбора программного продукта
Выбор программных продуктов производится по их функциональным возможностям и степени важности каждой возможности для будущего пользователя.
Каждая оценка определяется экспертно. Т.е. из группы будущих пользователей и потребителей каждый сотрудник выставляет свою оценку. В таблицу заносится общий результат каждой оценки эксперта (среднее арифметическое или среднее арифметическое с учетом веса каждого эксперта).
Для удобства, в нашей таблице последним листом сделан механизм расчета оценок 10 экспертов.
Критерий оценки продукта
В таблице рассматривается более 80 критериев оценки продуктов. При желании, Вы можете добавить свои критерии оценки. Таблица сделана в формате MS Excel.
В таблице приведены критерии оценки и выставлены предварительные оценки по Business Studio.
Критерии оценки следующие:
1. Формализация стратегии
1.1. Возможность ведения целей организации и их показателей
1.2. Возможность связи целей и показателей с процессами
1.3. Возможность создания графических стратегических карт Речь идет о системе сбалансированных показателей (ССП).
2. Средства контроля показателей
2.1. Возможность хранения плановых и фактических значений показателей
2.2. Возможность сбора значений показателей через MS Excel
2.3. Возможность автоматического сбора значений показателей
2.4. Возможность импорта значений показателей из других систем
2.5. Возможность графического отображения значений показателей
2.6. Возможность расчета значений показателей на основе других показателей Например, расчет Кол-во клиентов = Кол-во клиентов привлеченных + Кол-во клиентов, обратившихся повторно.
2.7. Возможность анализа значений показателей и вывода рекомендаций Подразумевается анализ системой данных бизнес-модели с рекомендациями изменения процесса или оргструктуры. Сюда не относится возможность создания отчетов (в пустой модели или созданных самостоятельно) которые бы выдавали данные, графики, краткие выводы на основе модели.
4.1. Возможность проведения функционально-стоимостного анализа (ФСА)
4.2. Возможность имитационного моделирования (запись модели процесса в конкретный момент)
4.3. Возможность анализа бизнес-модели на полноту данных Имеется ввиду, все ли процессы имеют входы/выходы, исполнителей и владельцев процессов.
5. Организационная структура
5.1. Возможность создания организационной структуры и ее связи с бизнес-процессами
5.2. Возможность традиционного отображения организационной структуры (диаграмма в виде дерева)
5.3. Возможность ведения требований к должности
5.4. Возможность ведения данных контактов по должности
5.5. Возможность создания отчета типа "Положение о подразделении" (ПоП)
5.6. Возможность создания отчета типа "Должностная инструкция" (ДИ)
5.7. Возможность создания отчета типа "Штатное расписание"
6. Формирование регламентной документации
6.1. Наличие готовых отчетов в "пустой" бизнес-модели (Регламент процесса, ДИ, ПоП и т.д.)
6.2. Возможность изменения существующих отчетов
6.3. Возможность создания отчета в формате MS Word
6.4. Возможность создания пользовательских отчетов (любая структура)
6.5. Возможность получения готовых отчетов, не требующих дополнительных вмешательств
6.6. Возможность получения сайта (веб-портал) с готовыми регламентами
6.7. Возможность в полученном сайте (веб-портале) предоставления примеров документов
6.8. Возможность вывода в отчетах графических элементов (диаграмма процесса, оргструктуры)
6.9. Возможность вывода в отчетах табличных данных
6.10. Возможность внешнего оформления отчетов по установленным в организации правилам
6.11. Возможность создания любых регламентов без программирования
6.12. Возможность создания регламентов программно на Visual Basic
6.13. Возможность создания регламентов на украинском языке
6.14. Проверка орфографии в отчете
7. Импорт/экспорт данных
7.1. Возможность импорта любых данных из других систем
7.2. Возможность настройки правил импорта пользователем Подразумевается самостоятельная настройка правил с непосредственным пользователем системы моделирования (не на уровне программирования).
7.3. Возможность импорта любых данных в формате xls
7.4. Возможность экспорта любых данных в формате xls
7.5. Возможность экспорта любых данных в формате xml
7.6. Возможность экспорта/импорта части бизнес-модели
7.7. Возможность переноса диаграммы или ее части в Word или Visio через Copy/Past
8. Совместное использование
8.1. Возможность совместной работы над одной бизнес-моделью в одно время несколькими пользователями
8.2. Возможность совместной работы с одним типом данных (справочников) в одно время несколькими пользователями Подразумевается работа несколькими сотрудниками, например, с разными ветками одной оргструктуры. 8.3. Возможность "забирать" часть модели для работы и "возвращать" обратно Подразумевается возможность изменения части модели вне основного сервера расположения базы модели (например, при командировке сотрудника).
9. Справочная система
9.1. Наличие актуального руководства пользователя
9.2. Наличие встроенной справочной системы
9.3. Наличие методик использования продукта под разные задачи
9.4. Наличие видео-роликов по работе с продуктом
9.5. Наличие пополняемого перечня вопросов-ответов по продукту
10. Требование к пользователям программного продукта
10.1. Возможность установки системы пользователем, не владеющим техническими навыками
10.2. Возможность создания отчетов пользователем без навыков программирования
10.3. Слабые знания нотаций бизнес-процессов системы моделирования читателям разработанных регламентов Подразумевается, насколько быстро и правильно непосредственные исполнители разработанных регламентов будут понимать описанные процессы.
11. Интерфейс
11.1. Поддержка drag&drop (тащи и бросай) при работе в программе Подразумевается заполнение свойств элементов простым перетаскиванием мышкой данных из других окон. Это сокращает время рутинных операций. 11.2. Интуитивно-понятный интерфейс
11.3. Русский язык интерфейса
11.4. Возможность создания меню для каждого пользователя
12. Безопасность
12.1. Возможность отслеживания действий пользователями
12.2. Возможность защиты своих данных пользователем
12.3. Возможность разграничения прав пользователей (читать, вносить изменения)
12.4. Возможность создания копии базы модели без знаний пользователем администрирования баз данных
13. Прочее
13.1. Возможность хранения в базе модели внешних регламентирующих документов/образцов документов
13.2. Возможность добавления новых свойств объектам системы без перепрограммирования
14. СМК
14.1. Возможность получения Политики по качеству
14.2. Возможность получения Руководства по качеству
14.3. Возможность соотношения описанных процессов и требований стандарта ISO 9001:2000 Подразумевается, установление связи типа "Требование стандарта – какими процессами реализуется – кто отвечает".
15. Управление проектами
15.1. Возможность закрепления ролей в проекте за элементами оргструктуры
15.2. Возможность создания структуры ролей проекта
16. Подготовка для автоматизации
16.1. Возможность проектирования перечня функций информационной системы и указание использования функций в бизнес-процессах
16.2. Возможность проектирования структуры данных
16.3. Возможность фиксации действий с полями документов в процессах
16.4. Возможность получения техзадания на автоматизацию процессов без дальнейшей доработки
17. Бюджетирование
Речь идет об описании структур бюджетов и процессов бюджетирования. Не имеется ввиду учетная система.
17.1. Возможность создания бюджетной структуры (БДДС, БДР, ББЛ)
17.2. Возможность создания финансовой структуры с закреплением оргструктуры
17.3. Возможность связи бюджетной и финансовой структуры
17.4. Возможность получения готового регламента бюджетирования
Чтение итоговой оценки
После того, как выставлены балы и значимость по каждому критерию продукта, производится итоговая оценка, которая рассчитывается по формуле
где 1 000 – коэффициент масштабности (для удобства чтения результата).
Логический смысл оценки следующий: чем больше сумма набранных балов продукта и чем меньше стоимость продукта – тем лучше. Наиболее подходящий продукт тот, у которого оценка наибольшая.
Для банка средних размеров (2000-3000 тыс. сотрудников) достаточно 3-4 специалиста по описанию бизнес-процессов. Сейчас в банке «Кредит Днепр» подразделение, занятое моделированием бизнес-процессов, состоит из 4 человек.
+380 (536) 701-601 
+380-(98) 689-05-21
