Написать программный код можно самостоятельно или обратившись в любую специализированную компанию. Однако именно методология является характеризующей чертой компании и именно от нее зависит, что получится в итоге. Вы получаете набор программного кода и интерфейсов или успешно внедренный продукт, решающий поставленные задачи. У разных компаний процент соотношения одного к другому отличается. Методология является выражением накопленного практического опыта.
Методология включает в себя принципы, согласованные методы и концепции по достижению целей. Целью в данном случае является решение проблем и задач бизнеса. Мы разрабатываем и постоянно улучшаем методологию ведения проектов, поэтому к моменту прочтения вами статьи что-то уже изменится. Если вы разработчик, то можете использовать данную статью, чтобы улучшить свои проекты и повысить процент доведенных до конца успешных предприятий. Если вы хотите автоматизировать свой бизнес, то поймете, как это лучше сделать.
В статье мы описываем применяемые нами методы, внедренные принципы и концепции для достижения двух видов целей.
Бизнес-аналитика
Метод включает в себя исследование бизнеса компании. Диалоги с владельцем, руководителями и сотрудниками. Выявление проблем, постановка целей автоматизации. Выявление пожеланий, как должно быть, с точки зрения ключевых пользователей.
Выявление истинной проблемы
Определение проблем в рамках концепции повышения эффективности производится путем выявления повторяющихся задач сотрудниками. Выписываются задачи, которые сотрудники или руководители выполняют каждый день, неделю, месяц. Подсчитывается, сколько времени затрачивается на их выполнение. В случае решения точечной проблемы производится анализ близлежащих бизнес-процессов, выявление причин возникновения проблемы.
Некоторые точечные проблемы могут быть связаны с проблемами делегирования, правильной постановкой задач, распределением нагрузки и другими факторами — задача не выполняется, но не понятно, по какой причине. Перед разработкой информационной системы необходимо определить, что именно нужно автоматизировать, чтобы решить проблему.
Структурирование бизнес-процессов
Составление последовательности действий для выполнения той или иной бизнес-задачи. Выявление точек автоматизации и способов объединения процессов на уровне структуры компании в единую систему. Включает построение логики движения заказа на производстве или путь сделки от первого контакта клиента до сопровождения после реализации. Определяется, что является результатом работы каждого сотрудника при выполнении каждой задачи в процессе. Может делиться на следующие блоки: привлечение клиента, работа с клиентом, производство продукта и внутренние процессы.
Составление видения решения
Включает в себя составление видения информационной системы. Какие разделы можно включить в информационную систему и как они будут решать поставленные задачи. Особое внимание уделяется принципу минимизации действий, о котором будет рассказано ниже. Предложение данного решения клиенту, добавление в видение дополнительных разделов и функций по мере поступления вводных данных.
Составление карты интерфейсов, сущностей и функций
Когда видение согласовано с заказчиком, есть общее понимание того, что будет в системе, составляется карта на основе MindMap. Она включает в себя все интерфейсы в системе, данные, которые обрабатываются и хранятся в ней и функции, определяющие особенности работы системы.
В процессе проектирования данная карта составляется несколько раз с разным уровнем детализации. По мере проектирования она дорабатывается, так как должна четко соответствовать прототипам и техническому заданию.
Прототипирование интерфейсов
Результатом является набор прототипов всех интерфейсов системы. Позволяет заказчику визуально продемонстрировать, как будет выглядеть система, какими в ней будут кнопки, поля, списки и фильтры. Данный метод позволяет выявить неучтенные и невысказанные изначально требования, которые становятся очевидными после ознакомления с интерфейсами. Производится корректировка и доработка прототипов.
Составление технического задания
Производится на основе согласованных прототипов и максимально детализированной карты проекта. Включает в себя технические требования, набор технологий, требования к качеству и соблюдению стандартов. В техническом задании фиксируются сущности (данные и их структура), описание интерфейсов и логика работы системы. Также в ТЗ мы включаем логические последовательности действий в системе для выполнения той или иной задачи.
Эти последовательности в будущем становятся основой карт тестирования. Техническое задание обязательно подробно разъясняется заказчику. Оно составляется таким образом, чтобы быть предельно понятным как заказчику, так и программистам.
Оценка проекта
Оценка бывает предварительной и окончательной. Предварительная оценка производится на основе первых карт интерфейсов, сущностей и функций. Она необходима для получения понимания стоимости проекта заказчиком. В ходе проектирования, уточнения требований, часто появляются новые разделы и функции, не обозначенные в первых картах и при предварительном проектировании. Окончательная оценка делается только после согласования прототипов и технического задания.
Создание дизайна интерфейсов
Используется для сокращения времени верстки проекта, исключает необходимость программистам самим додумывать внешний вид интерфейсов. Второй целью является окончательное понимание заказчиком конечного вида интерфейсов.
Разработка системы
Без данного метода достижение цели невозможно. Особенность данного средства достижения цели и успешность его применения зависят от соблюдения принципов определенности системы и оконченности этапа.
Проверка проекта
Применяется для того, чтобы цель была достигнута наиболее эффективно. В ходе проверки производится не только выявление технических ошибок. Мы используем трехэтапную проверку: проверка в отделе разработки и сдача менеджеру, полноценное тестирование менеджером, и только после этого отдаем на проверку заказчику. На каждом из этапов выявляются ошибки.
Основная задача этапа — выявить и исправить все недочеты до этапа внедрения. При тестировании заказчиком, как правило, определяется ограниченный круг сотрудников, а именно ключевых пользователей системы. Подзадача: чтобы до тестирования заказчиком ошибки не доходили.
Внедрение проекта
Это действие может выполняться самостоятельно заказчиком, или совместно с нами. В любом случае результатом является работа информационной системы в организации на реальных процессах с реальным количеством пользователей. По итогам данной работы можно судить о приросте эффективности. Прирост вычисляется путем подсчета количества решения бизнес-задач за единицу времени или сокращения времени на выполнение отдельной бизнес-задачи. Есть также другие факторы, например, сколько управленческих действий выполняется на основе полученной от системы информации.
Выявление дополнительных требований
После внедрения системы заказчик сам понимает, что необходимо улучшить, чтобы система делала организацию еще эффективней. Часто бывает так, что на основе опыта работы с шаблонными программами или не имея другого опыта, пользователи замалчивают проблемы, «мирятся» с тем, что не удобно. Это происходит из-за того, что они попросту не знают, карте именно изменения можно вносить. Бывает, что через год работы системы мы случайно узнаем, что сотрудник, выполняя уникальный бизнес-процесс, производит очень много действий в системе, хотя это можно сделать нажатием одной кнопки. Надо сразу сообщать о том, если что-то неудобно или требует лишних действий. Индивидуальные системы для того и делаются и тем и отличаются от шаблонных, что в них можно реализовать что угодно.
Принципы
Ниже мы рассмотрим основные принципы, которых мы придерживаемся в разработке и которые помогают системе работать эффективно.
Принцип определенности системы
Круг решаемых проблем, разделов и состав информационной системы должны быть четко определены, начиная со стадии обозначения целей и составления видения. В процессе проектирования нельзя допускать добавления в проект новых пожеланий, разделов и функций. Это приводит к рассогласованности проекта как в технической части, так и в бюджетной составляющей. Такая ситуация не нужна ни заказчикам, ни исполнителям. Но всегда, даже на поздних этапах проектирования есть желание добавить в систему «что-то еще» и заодно дополнительно автоматизировать что-либо в рамках системы. Это нормальное желание, но оно идет не на пользу проекту. Все пожелания необходимо выносить на другой этап работы над проектом.
Принцип завершенности этапа
С одного этапа на другой должна переноситься информация, исключающая возврат на прошлый этап. То есть, если изменения касаются проектирования на предыдущем этапе, приходится возвращаться назад, на то место, на котором проектировались данные или интерфейс и потом повторять весь путь заново. И чем раньше находится этап, на который необходимо вернуться, тем масштабней трагедия. Вот почему после того, как этап проектирования интерфейса пройден, желание добавить «еще кнопочку» уже выносится на доработки за пределы текущего проекта.
Опыт говорит о том, что внесение изменений сквозь этапы приводит к рассинхронизации проектирования, к ошибкам, исправлениям и уменьшению эффективности проекта. Именно поэтому по завершению каждого этапа его результаты изучаются и синхронизируются между заказчиком и разработчиками максимально детально.
Принцип соблюдения целей
При использовании каждого метода необходимо держать в голове цель, ради которой делается проект. Часто происходят ситуации по поговорке «аппетит приходит во время еды». Очень важно не делать те вещи, которые находятся вне целей проекта. Как и в бизнесе, в проектах иногда появляются паразитные вещи, которые не приносят никакой пользы, добавляются по принципу «пусть будут». Отрезвляющий эффект тут, как правило, приносит следующее понимание: «а готовы ли вы, как заказчик, за это платить?». Конечно, многие компании просто молча запишут пожелания и реализуют их, но это снизит эффективность проекта.
Также иногда происходит смешивание целей. Когда проект многоэтапный, он задуман как решение множества целей, по одной цели на этап. Имея полную картину будущего развития системы, можно заложить основу для решения задач на других этапах, делая последующие этапы логическим продолжением предыдущих с минимумом фундаментальных изменений системы. Хорошо, если есть возможность решать несколько целей с помощью одной системы. Но при каждом дополнении интерфейса нужно задавать себе вопрос «как это дополнение позволит достичь целей системы?».
Принцип минимизации действий
Суть заключается в минимизации количества действий с системой для выполнения задачи. В большей степени это касается функционала. И это больше принцип бизнеса, чем технический. Примитивный пример: чтобы создать заказ, нужно завести в систему контрагента. Неправильно будет сначала идти в раздел «контрагенты», создавать запись, потом идти в «заказы» и при создании нового заказа выбирать контрагента. Правильнее будет сделать так: определить, какие данные необходимо внести менеджеру, чтобы создать заказ. Например, для выставления счета необходим только ИНН и электронная почта (куда отправить счет). Значит менеджер должен указать только ИНН, электронную почту и название компании. Далее по одному клику позиция добавляется в заказ и нажимается кнопка, с помощью которой данные по контрагенту сохранятся в «контрагенты». Заказ создается на стадии отправления счета, который формируется и отправляется контрагенту. Фактически это бизнес-процесс, инкапсулированный в одно действие. Именно это является автоматизацией деятельности.
Данный принцип очень легко соблюдается при полностью индивидуальном проектировании и разработке и очень тяжело — при использовании шаблонных систем. В случае работы с индивидуальной системой (в отличии от готовых решений), которая будет разрабатываться на основе именно ваших бизнес-процессов и потребностей, эффективность будет гораздо более высокой, а затраченные на разработку средства будут вложением в рост продуктивности.
Именно благодаря соблюдению этого принципа и стоимости его соблюдения индивидуальная разработка в сравнении шаблонными системами намного эффективнее.
Концепции
Ниже приведены концепции, которые помогают в достижении целей по решению проблем и задач бизнеса, а также повышают эффективность работы. Обе указанные здесь концепции связаны с развитием компаний.
С помощью систем автоматизации можно решать проблемы или повышать эффективность работы (при развитии компании или при стабильной работе). Однако нельзя пытаться спасти компанию с помощью этих систем. Это неверный путь, который не приводит к ожидаемому результату.
Концепция решения проблемы
Согласно данной концепции подбирается набор методов для решения проблемы заказчика. Возникновение проблемы, как правило, связано с развитием компании. Например, руководитель замкнул на себя подписание всех счетов в оплату. Компания выросла, и руководитель только тем и занимается, что подписывает счета, или начал тратить на это непозволительное количество времени. Другой пример: руководитель контролировал все сделки менеджеров вручную, но менеджеров и сделок стало много, контролировать все стало невозможно.
Проблема, которая высказывается заказчиком, находится на поверхности и может быть любой. Например:
- избыток бумажной работы;
- менеджеры забывают про клиентов, забывают совершать звонки;
- задачи не выполняются, отсутствует контроль за их выполнением;
- производство постоянно проваливает сроки;
- требуется личное общение для выполнения действия, например, передачи бумаг или информации.
Как правило, эти проблемы лежат не в плоскости информационных систем, а в плоскости бизнес-процессов. Но при помощи метода бизнес-анализа они выявляются, решаются, а информационная система в будущем помогает их контролировать.
Например, проваливать сроки производства компания может по следующим истинным (выявленным в ходе анализа) причинам:
- об отсутствии комплектующих для выполнения заказа узнают только тогда, когда они понадобились. Комплектующие заказываются, производство ждет поступления заказа;
- несколько руководителей жонглируют заказами, каждый раз ставя свой на производство раньше других;
- нет понимания истинных сроков и объема готовности заказа в любой момент времени;
- ежедневное ручное распределение ресурсов (станков, материалов, сотрудников) происходит неэффективно, что приводит к простоям ресурсов, из-за чего теоретическое планирование не совпадает с реальными сроками.
Концепция включает в себя методы бизнес-анализа, нацеленные на выявление истинных причин проблемы. Целью в данном случае является решение проблемы, а проектируемая ERP-система нацелена уже на техническую поддержку этого решения.
Как правило, решение проблемы является основной причиной становления организаций на путь автоматизации и решение проблемы является лишь первым шагом на этом пути.
Концепция повышения эффективности
В данную колесницу садятся системные и состоявшиеся компании и руководители. Повышение эффективности — альтернатива расширения путем найма сотрудников по прогрессии при росте компании. Также это решение для крупных компаний, для которых прирост эффективности на несколько процентов — это суммы, окупающие во много раз затраты на разработку ERP (именно эффективной, удобной и быстрой ERP).
Концепция включает в себя методы, нацеленные на поиск точек повышения эффективности работы, сокращение времени на выполнение действий и прохождение бизнес-процессов.
При создании системы по данной концепции особое внимание уделяется принципу сокращения количества кликов и компоновке информационных блоков на прототипах.
В ходе бизнес анализа выполняется исследование компании или отдела целиком. По данной концепции может быть выбран путь повышения эффективности отдельного отдела или подразделения. В работе отдела или компании в целом строятся и детализируются цепочки бизнес задач и выявляются места, в которых можно существенно ускорить процессы с помощью систем автоматизации.
Зачем нужна методология
Есть такой термин — эффект Даннинга-Крюгера. Он встречается в разной мере во всех сферах работы. Сталкиваясь по роду деятельности с участниками процесса разработки информационных систем, можем сказать точно, что в области программной разработки он распространен широко. Наличие или отсутствие методологии - лакмусовая палочка наличия Крюгеризма в процессе разработки. Наличие методологии и структурированных подходов к созданию информационных проектов является ключевым фактором успешности проектов. Если взять на заметку методы и концепции, которые мы описали в статье, вы сможете значительно поднять уровень эффективности и качества при разработке систем автоматизации в вашей компании.