Файл: Электронный магазин: универсализм против спецификации.pdf

Глава 2. Системы универсальные и на основе спецификации.

2.1 Интернет-магазин «Орехи и сухофрукты».

Допустим, я предприниматель. У меня в планах открыть свой бизнес по продаже орехов и сухофруктов. Орехи и сухофрукты доставляют мне поставщики из жарких стран, например из Центральной Азии. Сбыт продукции предполагается посредством интернет-магазина с доставкой. Оплата принимать непосредственно на сайте либо в момент доставки. Также отслеживать запас продукции и в случае достижения минимального порога, размещать заказ поставщикам. Вдобавок я хотел бы держать базу клиентов, чтобы в определенные дни предлагать продукцию со скидкой, например в дни рождения. И так, попробуем ниже в таблице 1 отобразить задачи тезисно и отнести их к соответствующим зонам ответственности, а также к типу учетной системы.

Таблица 1 – «Задачи, зоны и системы»

Теперь попробуем подобрать под вышеперечисленные задачи универсальную систему или оформить спецификацию, и в соответствии со спецификацией разработать либо настроить существующую систему.

2.2 Система на основе спецификации.

Систему для электронного магазина можно разработать своими силами, если компания имеет свой штат специалистов по информационным технологиям. Если компания не располагает такими специалистами, то может заказать компании, которая специализируется на разработке программных продуктов и различных решений для автоматизации бизнеса. Хорошо если заказчик немного разбирается в информационных технологиях, но и отсутствие таковой не является барьером. Разработка любого программного решения потребует сначала написания спецификации. Спецификация на будущий программный продукт пишется на основе требований заказчика. Исполнитель вместе с заказчиком вырабатывают требования к будущему программному решению. Заказчик подробно описывает как устроены бизнес-процессы в его компании. Исполнитель может предложить внести улучшения в текущие бизнес-процессы, но важно, чтобы при разработке требований, исполнитель оперировал теми же терминами, что и заказчик.

В процессе проектирования, определяются объекты проблемной области, места, участники и их отношения. Рассмотрим различные зоны автоматизации.

2.2.1 Склад

WMS – это автоматизированная система управления складскими бизнес-процессами. Другими словами, WMS – это инструмент, при помощи которого можно формализовать выполнение складских бизнес-процессов таким образом, чтобы обеспечить синхронное изменение реальных процессов на складе одновременно с изменениями в данных бизнес-процессах. То есть получить возможность при помощи настроек в АРМе пользователя непосредственно влиять на реальные процессы, происходящие на складе.

С точки зрения IT – информационных тех-нологий, WMS может быть частью КИС (на одной платформе с КИС) или быть отдельным блоком на отдельной платформе и обмениваться данными с другими программами, входящими в общую КИС, при помощи соответствующих блоков синхронизации.

Есть множество ошибочных определений термина «WMS», такое, например как: «WMS – это система управления складом».На самом деле, это совсем не так. WMS – это всего лишь инструмент (программа), при помощи которой можно автоматизировать некоторые складские бизнес-процессы. То есть это всего лишь один из множества блоков (частей), некий «автоматизатор», который входит в общую систему управления складом, наряду с другими блоками (например, блоком управления складским персо-налом или блоком управления качеством товара на складе или блоком поддержания бесперебойной работы складского оборудования), а, отнюдь, невся система.

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

Практически любой стандартный складской бизнес-процесс состоит из следующих основных шагов (бизнес-процессов II уровня), соответствующих следующим складским операциям (рассмотрим на примере типичного бизнес-процесса дистрибьюторского бизнеса):

Шаг №1. Приемка товара

Шаг №2. Размещение товара

Шаг №3. Пополнение ячеек

Шаг №4. Комплектация заказов

Шаг №5. Комплектация маршрутов

Шаг №6. Отгрузка

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

2.2.2 CRM.

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

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

Изучаем процесс продажи. Этот этап работы одинаково важен как для внедрения CRM силами сотрудников компании, так и в случае привлечения внешнего специалиста. Очень важно понять, каким образом отдел продаж работает в текущее время, и получить ответы на такие вопросы:

1. Каким образом компания получает новых клиентов? Откуда приходят входящие запросы или информация о заинтересованных лицах (компаниях)?

2. Как большинство менеджеров работают с клиентом – от первого контакта до завершения сделки. Какие основные этапы в работе они могут выделить?

3. Что происходит в случае отказа на том или ином этапе работы?

4. Ведется ли какая-то работа после продажи, если да – какая?

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

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

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

Ниже перечислены возможности, которыми должна обладать CRM-система:

• Планирование дел;
• Ведение клиентской базы и отчетности;
• Бизнес-процессы;
• Интеграция с интернет-магазином;
• Интеграция с бухгалтерской программой, например 1С;
• Настройки права доступа;
• Контроль сроков;
• Снижение расходов;
• Увеличение продаж;
• Контроль качества работы;

Список выше можно дополнить такой возможностью, как интеграция с IP-телефонией. Широко распространена интеграция с такой IP-телефонией как Asterisk. Это проект с открытым исходным кодом, и он доступен для свободного пользования. На официальном сайте Asterisk есть достаточно хорошая документация по этой системе. Asterisk предоставляет интеграцию через свои протоколы: AMI (Asterisk Management Interface) и ARI (Asterisk REST Interface). AMI – это достаточно старый метод интеграции. ARI – это достаточно новый метод интеграции, он появился приблизительно 2 года назад, по сути это HTTP REST протокол.

2.2.3 СУБД.

Практически любая информационная система генерирует большой поток данных и эти данные должны где-то храниться. Для таких целей используют СУБД – систему управления базами данных. В мире много различных СУБД-систем. От малых «легковесных», до больших, корпоративного масштаба.

СУБД — это общий термин, относящийся ко всем видам абсолютно разных инструментов, от компьютерных программ до встроенных библиотек. Эти приложения управляют или помогают управлять наборами данных. Так как эти данные могут быть разного формата и размера, были созданы разные виды СУБД.

СУБД основаны на моделях баз данных — определённых структурах для обработки данных. Каждая СУБД создана для работы с одной из них с учётом особенностей операций над информацией.

Хотя решений, реализующих различные модели баз данных, очень много, периодически некоторые из них становятся очень популярными и используются на протяжении многих лет. Сейчас самой популярной моделью является реляционная система управления базами данных (РСУБД). Помимо реляционной модели, есть относительно новая модель называемая NoSQL.

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

РСУБД требуют чётких и ясных схем — не стоит путать со специфическим определением для PostgreSQL — для работы с данными. Эти рамки, определённые пользователем, задают способ их хранения и использования. Схемы очень похожи на таблицы, столбцы которых отражают порядковый номер и тип информации в каждой записи, а строки — содержимое этих записей.

Самыми популярными РСУБД сейчас являются:

• SQLite: очень мощная встраиваемая РСУБД.
• MySQL: самая популярная и часто используемая РСУБД.
• PostgreSQL: самая продвинутая и гибкая РСУБД.

NoSQL-СУБД не используют реляционную модель структуризации данных. Существует много реализаций, рещающих этот вопрос по-своему, зачастую весьма специфично. Эти бессхемные решения допускают неограниченное формирование записей и хранение данных в виде ключ-значение.

В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB, позволяют группировать коллекции данных с другими базами данных. Такие СУБД хранят данные как одно целое. Эти данные могут представлять собой одиночный объект наподобие JSON и вместе с тем корректно отвечать на запросы к полям.

NoSQL базы данных не используют общий формат запроса (как SQL в реляционных базах данных). Каждое решение использует собственную систему запросов.

Из информации выше о СУБД, все таки для электронного магазина, лучше использовать РСУБД.

2.2.4 CMS.

В электронном магазине (интернет-магазине), пользовательским интерфейсом для покупателей/посетителей служит веб-сайт, который работает в приложении-браузере. Дизайн и юзабилити (удобство) веб-сайта – залог того, что у посетителей останутся положительные впечатления от пользования веб-сайтом, чаще называют этот термином UX (пользовательский опыт).

При разработке веб-сайта могут быть использованы так называемые CMS-системы. CMS — это инструментальная среда для создания и администрирования сайта без знаний языков программирования (Content Management System - система управления содержимым). Система управления сайтом, или CMS-движок, содержит готовые шаблоны структуры, набор функций для дизайна и наполнения данными. Это инструментальная среда для создания и администрирования сайта без знания языков программирования. CMS сайта позволяет удобно обслуживать ресурс – управлять доступом к контенту, изменять данные на страницах, отправлять почту.