Разработка информационной системы интернет-магазина бытовой техники

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

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

Бизнес-инжиниринг в указанной трактовке это наиболее передовая технология не только для Беларуси, но и для Запада. Идея менеджмента на основе бизнес-инжиниринга – может стать национальной идей для России, подобно идее качества, которая породила японское экономическое чудо. (Опять же – эти идеи исключительно хорошо дополняют друг друга). Задача российского менеджмента состоит не только в том, чтобы воспроизводить западные технологии управления 50-летней давности (бюджетирование, массовый маркетинг, управление по целям) или вдогонку осваивать сегодняшние (CRM, BalancedScorecard), а в игре на опережение – внедрение в свою практику технологий управления завтрашнего дня. Управление перестройкой структур и процессов, протекающих на предприятии в настоящий момент должно стать массовой специальностью! Модели предприятия, поддерживаемые инструментальными средствами должны стать неотъемлемой частью информационной системы предприятии, предоставляя его менеджерам возможность наблюдения точной и полной картины организации бизнеса, а также ее перестройки. [17]

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

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

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

Решение этой задачи также очень важно для разрешения скрытого противоречия, содержащегося в новой редакции стандартов ИСО9000:2000: с одной стороны в них декларируется принцип постоянного улучшения (изменения!) процессов компании, с другой - приведены достаточно жесткие требования к документированию деятельности. Отсутствие адекватных средств поддержки самодокументируемости процессов – может привести к следующему. Либо документация будет все время отставать от развития процессов компании и процессы будут выполняться по нечетким правилам, что чревато ошибками и потерей качества управления. Либо решения об изменениях могут быть приостановлены, т.к. только что закончив утомительный труд по документированию процессов, компания не находит в себе сил пройти его еще раз.

Надо заметить, что в современном менеджменте наблюдается сильная зависимость возможности применения тех или иных методов управления от наличия адекватных средств их информационной поддержки. Освоив средства накопления и обработки информации в определенной области, предприятие получает в свое распоряжение новый вид ресурсов - «информационных» [18]

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

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

Глава 2. Методологии моделирования бизнес-процессов

2.1.Методология структурного анализа и проектирования (SASD)

Осуществление реинжиниринг необходимо начать с выбора наиболее

подходящей методологии описания (или моделирования) бизнес-процессов.

Наиболее простыми являются:

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

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

Методология структурного анализа и проектирования (SASD)

Эта методология основана на классической и весьма успешной методологии

структурного проектирования программного обеспечения и информационных систем.

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

Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

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

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

Набор диаграмм состояния процессов играет ту же роль, что и динамическая модель в методологии OMT.

Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии OMT.

Так в методологии SASD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.

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

Но в методологии SASD ведущей является функциональная модель (набор ДПД), на втором месте по важности стоит динамическая модель и на последнем месте - объектная модель. Таким образом, в методологии SASD проектируемая система описывается с помощью процедур (процессов), что несколько противоречит объектно-ориентированному подходу. Методология OMT гораздо ближе к нему: в ней моделирование концентрируется вокруг объектной модели, т.е. вокруг объектов, из которых строится проектируемая система.[6]

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

В то же время методология SASD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

2.2. Методология SADT

Представляет собой дальнейшее развитие методологии структурного анализа и проектирования.

   Методологию SADT/IDEF0, применяется при проектировании информационных систем для описания и анализа  бизнес-процессов подвергаемых автоматизации и информатизации.

     SADT (Structured Analysis and Design Technigue) - разработана в 1973г. Дугласом Т. Россом. SADT, используется в военных, промышленных и коммерческих организациях для решения широкого спектра задач: программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем,  управление финансами и материально-техническим снабжением и др. Поставив своей целью описание системы в целом, создатели SADT предложили графический язык и набор процедур анализа, которые могут быть использованы для  понимания системы прежде, чем можно представить ее воплощение.

Основными концептуальными элементами этой методологии являются:

1) графическое представление объекта анализа. Графика SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;

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

- ограничение количества блоков на каждом уровне декомпозиции (как правило, 3–6 блоков);

- связность диаграмм через иерархическую нумерацию блоков;

- уникальность меток и наименований (отсутствие повторяющихся имен);

- наличие синтаксических  правил для графического отображения блоков и дуг;

- разделение ресурсного входа и целевого управления (правило определения роли данных).

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

1)   Визуализация и наглядное представление бизнес-процессов;

2) Простота в освоении и наличие компьютерных программ позволяющих упростить построение моделей;

3) Построение моделей «AS-IS - как есть» и TO-BE - «как должно быть», и, следовательно, это позволит отслеживать по моделям возникновение возможных проблемных ситуаций в процессе внедрения системы качества;

5) Возможность интеграции в модель других моделей построенных на основе других методологий входящих в семейство IDEF;

6) Возможность отображения на модели всех значимых параметров процессов;

7) Модели могут быть положены в основу документирования бизнес-процессов Данной методологией, как правило, владеют большинство IT специалистов, наличие «общего языка» может упростить внедрение информационной системы. [11]

2.3. Методология  IDEF

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

Методология IDEF состоит из 14 компонент, наиболее важными из которых являются: