Роль бизнес-процессов в проектировании интерфейсов

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

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

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

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

Итак, при разработке проекта получается следующая цепочка:

image

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

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

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

Если система бизнес-процессов не так сложна или вы автоматизируете один из процессов, его можно описать самостоятельно.

Каким образом это можно сделать? Изначально проводится опрос участников процесса и делаются заметки на бумаге. Необходимо выяснить всех участников процесса, исполнителей, передаваемую информацию, входы и выходы процесса и ответственных. Если процессов много, рекомендуется использовать специальное ПО для бизнес-моделирования, это существенно облегчит хранение процессов и вычисление пересечения данных между собой, позволит проводить анализ результатов бизнес-процессов. Примером данных систем являются: Business Studio, Aris, AllFusion Process Modeler, ELMA.

Если бизнес-процесс не является сложным, можно обойтись просто графическим отображением, для этого можно использовать специализированное программное обеспечение, такое как: BizAgi Process Modeler, Bonita Open Solution, ActiveBPEL Engine и др. или же графические редактор для создания блок-схем: Microsoft Visio, OpenOffice.org Draw, yEd Graph Editor. Какой бы инструмент не использовался главное это достижение цели в данном случае описанный бизнес-процесс.

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

Методологии описания бизнес-процессов появились уже давно, и если вы преследуете цель полноценного описания бизнес-процессов в организации, можно обратиться к одной из них.
Я перечислю основные методологии, которые используются сейчас: ARIS, DFD, IDEF0, IDEF3, BPMN, EPC, FlowChart, и др. Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Для каждого объекта и связей характерны ряд параметров, или атрибутов, отражающих определённые характеристики реального объекта (номер объекта, название, описание, длительность выполнения (для функций), стоимость и др.).

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

Пример использования нотации IDEF0:

image

Пример использования нотации EPC:

image

Пример использования нотации Cross Functional Flowchart:

image

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

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

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

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

Подробнее
Реклама

Комментарии 7

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

      А какими продуктами пользуетесь лично Вы для описания бизнес-процессов из перечисленных? с какими посоветуете поиграться для начала?

      Ну и конечно, статья получилось бы интересней, если бы в ней было больше жизни, реального опыта!
        0
        Спасибо, для начала рекомендую понять процесс создания блок-схем используя простые программы: OpenOffice.org Draw, yEd Graph Editor, для них особых знаний не требуется. После, можно использовать более сложные программы как Microsoft Visio. Если хотите пользоваться профессиональным программным обеспечением для создания бизнес-процессов, как правило их используют бизнес-аналитики, для меня ближе Business Studio у них есть много обучающего материала на русском и на их теории можно освоить методологии (нотации).
          0
          А какой инструмент использован для первой и последней схемы? Он OpenSource?
          0
          Первая схема Visio, а последняя yEd Graph Editor (бесплатный для использования)
            0
            magicstyle,
            спасибо за статью, очень вовремя нашла.

            По опыту, подскажите, что посоветуете использовать (и методологию, и ПО), для описания одного участка бизнеса, а не всей структуры?
            На участке: входящая-исходящая информация часто повторяется, отчетности нет, ролей 5-6.
              0
              В вашем случае рекомендую использовать методологию Cross Functional Flowchart, но учитывая количество ролей возможно и EPC, программное обеспечение можно использовать yEd Graph Editor

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

            Самое читаемое