Проектирование интерфейсов в создании программного обеспечения для организаций, довольно интересная деятельность, сталкиваешься с разными задачами. Но, с чего необходимо начинать для того, чтобы разработать качественный интерфейс программного продукта? С разговора с заказчиком? Да, но полную информацию при общении с руководителем организации не всегда удается получить.
Проектирование интерфейсов в программных продуктах, которые разрабатываются для автоматизации бизнеса, необходимо начинать с анализа деятельности, а еще глубже с анализа бизнес-процессов и только точное понимание бизнес-процесса дает возможность видеть цели, которые должен выполнять программный продукт. Понимание целей приводит к ясному и логическому проектированию интерфейса.
Для автоматизации бизнеса необходимо иметь его описание, описанием бизнеса занимаются не автоматизаторы, программисты или проектировщики, описанием бизнес-процессов занимаются бизнес аналитики и менеджеры, автоматизировать можно только ту деятельность, которая прошла логических контроль с их стороны. Внедрение компьютерных технологий поверх неверно организованных бизнес-процессов только вредит, если автоматизировать «бардак» в результате получится «автоматизированный бардак».
А каким же образом бизнес-процессы связаны с интерфейсами? Интерфейс является механизмом взаимодействия пользователя с программным продуктом, что бы интерфейс отобразить на экране, необходимо провести предпроектный анализ, который выделит суть и цели программного продукта, исходя из целей и бизнес-процессов полученных в предпроектном анализе, можно проектировать интерфейс.
Итак, при разработке проекта получается следующая цепочка:
Для раскрытия темы давайте, рассмотрим одну из ее частей – анализ и исследование, именно в этой части разработки программного продукта необходимо выяснить, для чего данный продукт нужен.
Автоматизация бизнес-процессов подразумевает под собой разработку ПО по уже описанным бизнес-процессам, но как поступить, если бизнес-процессы в организации не описаны, в данном случае не следует догадываться, каким образом работает компания и заниматься самодеятельностью не подготовившись должным образом, иначе это влетит в затягивание сроков разработки, не установленным расходам и выяснением отношений с заказчиком.
Поступить можно двумя путями, если объем бизнес-процессов довольно сложен, организация крупный заказчик, есть смысл обратится к сторонней организации за помощью в описании бизнес-процессов. Они опишут структуру организации, бизнес-процессы, сделают их коррекцию, создадут пакет должностных инструкций для сотрудников компании, а также видение и стратегию организации на будущее. После необходимо понять какая деятельность будет автоматизироваться? Чтобы ответить на этот вопрос нужно понять, что именно не устраивает в текущей работе организации. Такими параметрами могут стать: время выполнения процесса, стоимость выполнения процесса, качество (количество ошибок и сбоев). Выделенные бизнес-процессы необходимо детально описать, сделав акцент на информации (используемые документы, отчеты), которая необходима для осуществления какого-либо действия процесса или является результатом его выполнения.
Если система бизнес-процессов не так сложна или вы автоматизируете один из процессов, его можно описать самостоятельно.
Каким образом это можно сделать? Изначально проводится опрос участников процесса и делаются заметки на бумаге. Необходимо выяснить всех участников процесса, исполнителей, передаваемую информацию, входы и выходы процесса и ответственных. Если процессов много, рекомендуется использовать специальное ПО для бизнес-моделирования, это существенно облегчит хранение процессов и вычисление пересечения данных между собой, позволит проводить анализ результатов бизнес-процессов. Примером данных систем являются: 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:
Пример использования нотации EPC:
Пример использования нотации Cross Functional Flowchart:
Какие бы методологии в описании вы не использовали главное добиться полного понимания бизнес-процесса, таким образом, вы перейдете к следующему этапу — формированию требований к программному продукту и выявлению задач выполняемых с помощью ПО.
Дальнейший процесс проектирования будет складываться из создания черновых интерфейсов и прототипов ПО, основываясь на данных полученных из бизнес-процесса. Разработка черновых прототипов программы позволит лучше увидеть функциональность проектируемого интерфейса.
Понимание целей и задач разрабатываемого ПО является начальным этапом работы для проектировщика интерфейсов, а описание бизнес-процессов послужит хорошим инструментом для достижения положительных результатов в проектировании.
Список целей и задач, а также подключение маркетологов к разработке интерфейса расставят приоритеты между элементами информации предлагаемой пользователю, упростят работу с ПО, и повысят эффективность конечной эргономики программного продукта.
Проектирование интерфейсов в программных продуктах, которые разрабатываются для автоматизации бизнеса, необходимо начинать с анализа деятельности, а еще глубже с анализа бизнес-процессов и только точное понимание бизнес-процесса дает возможность видеть цели, которые должен выполнять программный продукт. Понимание целей приводит к ясному и логическому проектированию интерфейса.
Для автоматизации бизнеса необходимо иметь его описание, описанием бизнеса занимаются не автоматизаторы, программисты или проектировщики, описанием бизнес-процессов занимаются бизнес аналитики и менеджеры, автоматизировать можно только ту деятельность, которая прошла логических контроль с их стороны. Внедрение компьютерных технологий поверх неверно организованных бизнес-процессов только вредит, если автоматизировать «бардак» в результате получится «автоматизированный бардак».
А каким же образом бизнес-процессы связаны с интерфейсами? Интерфейс является механизмом взаимодействия пользователя с программным продуктом, что бы интерфейс отобразить на экране, необходимо провести предпроектный анализ, который выделит суть и цели программного продукта, исходя из целей и бизнес-процессов полученных в предпроектном анализе, можно проектировать интерфейс.
Итак, при разработке проекта получается следующая цепочка:
Для раскрытия темы давайте, рассмотрим одну из ее частей – анализ и исследование, именно в этой части разработки программного продукта необходимо выяснить, для чего данный продукт нужен.
Автоматизация бизнес-процессов подразумевает под собой разработку ПО по уже описанным бизнес-процессам, но как поступить, если бизнес-процессы в организации не описаны, в данном случае не следует догадываться, каким образом работает компания и заниматься самодеятельностью не подготовившись должным образом, иначе это влетит в затягивание сроков разработки, не установленным расходам и выяснением отношений с заказчиком.
Поступить можно двумя путями, если объем бизнес-процессов довольно сложен, организация крупный заказчик, есть смысл обратится к сторонней организации за помощью в описании бизнес-процессов. Они опишут структуру организации, бизнес-процессы, сделают их коррекцию, создадут пакет должностных инструкций для сотрудников компании, а также видение и стратегию организации на будущее. После необходимо понять какая деятельность будет автоматизироваться? Чтобы ответить на этот вопрос нужно понять, что именно не устраивает в текущей работе организации. Такими параметрами могут стать: время выполнения процесса, стоимость выполнения процесса, качество (количество ошибок и сбоев). Выделенные бизнес-процессы необходимо детально описать, сделав акцент на информации (используемые документы, отчеты), которая необходима для осуществления какого-либо действия процесса или является результатом его выполнения.
Если система бизнес-процессов не так сложна или вы автоматизируете один из процессов, его можно описать самостоятельно.
Каким образом это можно сделать? Изначально проводится опрос участников процесса и делаются заметки на бумаге. Необходимо выяснить всех участников процесса, исполнителей, передаваемую информацию, входы и выходы процесса и ответственных. Если процессов много, рекомендуется использовать специальное ПО для бизнес-моделирования, это существенно облегчит хранение процессов и вычисление пересечения данных между собой, позволит проводить анализ результатов бизнес-процессов. Примером данных систем являются: 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:
Пример использования нотации EPC:
Пример использования нотации Cross Functional Flowchart:
Какие бы методологии в описании вы не использовали главное добиться полного понимания бизнес-процесса, таким образом, вы перейдете к следующему этапу — формированию требований к программному продукту и выявлению задач выполняемых с помощью ПО.
Дальнейший процесс проектирования будет складываться из создания черновых интерфейсов и прототипов ПО, основываясь на данных полученных из бизнес-процесса. Разработка черновых прототипов программы позволит лучше увидеть функциональность проектируемого интерфейса.
Понимание целей и задач разрабатываемого ПО является начальным этапом работы для проектировщика интерфейсов, а описание бизнес-процессов послужит хорошим инструментом для достижения положительных результатов в проектировании.
Список целей и задач, а также подключение маркетологов к разработке интерфейса расставят приоритеты между элементами информации предлагаемой пользователю, упростят работу с ПО, и повысят эффективность конечной эргономики программного продукта.
