Отчёт, И_13
.pdfТакже это веб-приложение позволит весьма успешно предоставлять нужную информацию и для самой отрасли в системе АСУ ТОиР, которая на данный момент не автоматизирована, а именно, ЖКХ. Сегодня спрос на услуги организации по продаже, ремонту и модернизации станочного оборудования со стороны организаций ЖКХ будет увеличиваться и, соответственно, приведет к росту клиенткой базы для этих организаций. При этом поиск основной информации будет осуществляться именно через сеть интернет.
Следовательно, для организации по продаже, ремонту и модернизации станочного оборудования разработка такого веб-приложения будет весьма необходимым и оптимальным решением с целью увеличения уровня конкурентоспособности организации и автоматизации работы не только с потенциальными, но и с уже существующими клиентами.
1.2 Существующие подходы к проектированию и разработке веб-
приложений для организаций по ремонту, продаже и модернизации станочного оборудования
В самом начале своей истории абсолютно все программы обычно строились без соблюдения каких-либо архитектурных принципов, программа состояла из некоторого множества идущих друг за другом строк: без каких-
либо классовых наследований, зависимостей и иных современных возможностей, которые есть у языков программирования. Но стремление упростить разработки и структурировать как код, так и само приложение могло быть предпосылкой к возникновению такого понятия как «архитектура ПО
(программное обеспечение)». Рассмотрим три самых популярных подхода к такому архитектурному проектированию различных веб-приложений:
Модульный подход SOA[1], Монолитный или Сервис-ориентированный.
Примером монолитной архитектуры может быть любое приложение,
даже которое включает в себя разнообразные классы. Необходимо отметить,
12
что может показаться, что это приложение в данный момент становиться модульным, но это совсем не так, а именно, по праву монолитное приложение может включать в себя модули, но в то же время они частично или же полностью каким-то образом зависят друг от друга.
Рисунок 1.2 – Структура обычного веб-приложения
На рисунке 1.2 приведён пример структуры простого веб-приложения,
который состоит из базы данных, сервера, а также межсетевого экрана, как правило, хостинг отвечает за защиту, однако если создавать что-то своё, то придётся защищаться самому.
Модульная же в отличие от монолитной архитектуры подразумевает разбитие абсолютно всего функционала приложения на определенные отдельные модули. Каждый из них отвечает за какую-то часть функционала этого приложения так, что саму модульную архитектуру можно охарактеризовать как совокупность некоторого числа монолитных модулей внутри этого одного приложения. Каждый модуль данного приложения функционально не зависит от другого, поэтому его использование в разных участках всего кода не будет создавать каких-либо сбоев в работоспособности,
можно сказать, что это предоставляет, так называемую, простоту рефакторинга и переноса границ данного модуля. Требуется отметить, что в случае изменения
13
одного из модулей, другие модули не будут затронуты, следовательно,
решается важная задача отладки в компьютерной разработке и программировании [3]. Всё, что будет необходимо, это только подстроить остальные модули, которые используют функционал изменённого модуля под новые требования и возможности последнего, если же в нём изменения могут вызвать сбои в работе этого приложения. Помимо этого, все модули находятся в синхронном порядке во взаимодействии друг с другом, так как расположены на одной и той же аппаратной части, а, если необходимо, для модуля возможно выделить специальную отдельную базу данных либо часть данных, с которыми данный модуль будет совершать работу. К примеру, современные PHP
фреймворки, используемые для быстрой разработки разных веб-приложений.
Каждый созданный класс-модуль в этих фреймворках имеет функционал какой-
либо конкретной направленности и никаким образом напрямую не взаимодействует с той частью этого приложения, для которой он не был предназначен изначально.
Рисунок 1.3 –. Модульное приложения состоящее из клиентской
(Frontend) и серверной (Backend) части
14
На рисунке 1.3 изображена в качестве примера структура модульного приложения, состоящего из двух модулей: серверной и клиентской части.
Каждая из частей осуществляет свой определенный функционал: за вывод пользовательского интерфейса отвечает клиентская часть, а серверная часть – за всю оставшуюся бизнес-логику этого приложения, выполняя на стороне сервера все необходимые вычисления, включая работу с базой данных. Как изображено на картинке, клиентская часть применяет библиотеку React с целью вывода получаемых данных от серверной части. Последняя, в свою очередь, в
виде языка программирования использует PHP и по запросу от клиентской части отдаёт определенный набор данных, также включает и всю основную бизнес-логику данного приложения, так как клиент должен всегда оставаться насколько возможно легким в рамках размера итогового файла. По сути,
критичным не является что конкретно применяется на серверной и клиентской части. Клиентом может быть и Angular, и Vue.js, и «чистый» JS, а серверная часть может быть написана на C#, Java, NET, C++ и иных языках. Модульный подход дал возможность разрабатывать по сравнению с предыдущими наиболее Возможность разработки сервис-ориентированным подходом полного приложения предоставляет способ разработки таких сервисов на различных языках программирования. Например, сервис по доставке сообщений может быть написан на NodeJS, где в качестве языка программирования применяется
JavaScript, вместе с тем как основное же приложение, которое использует данный сервис, может также состоять из связки PHP на серверной части и React
на клиентской. С целью взаимодействия таких двух частей требуется лишь правильно применить в основной части приложения программный интерфейс сервиса. Разработка этих сервисов происходит обычно отдельно друг от друга,
поэтому какие-либо изменения в коде одного сервиса будут оказывать влияние только на него самого при условии, если в программном интерфейсе данного сервиса не изменилась выдача данных, что встречается очень редко, так как формат вывода определяется на первых этапах разработки подобного сервиса.
15
Рисунок 1.4 – Сервис-ориентированная архитектура приложения
На рисунке 1.4 представлена топология сети сервис-ориентированного веб-приложения типа «кольцо». В разрезе приложения пользователь попадает всегда на сервер этого приложения с IP-адресом 192.168.0.30 и соответственно предоставляет для работы с пользователем общий интерфейс. Допустим, что это веб-приложение отправляет уведомления и почту, следовательно, или данный функционал требуется реализовать на самом сервере приложений, что представляется модульным подходом, или же создать ему отдельный сервер в виде отдельного сервиса, что и отражено выше на картинке. Сервер отправки уведомлений и почты обеспечивает работу одноимённого сервиса, который расположен по IP-адресу 192.168.0.31 и его основная задача заключается в отправке различного рода уведомлений и почты. Также сервис предоставляет интерфейс с целью взаимодействия с ним иным сервисам. Так сервер приложения, если необходимо отправить уведомление одному или более
16
пользователям, будет осуществлять отправку запроса на соответствующий сервис, облегчая при этом работу себе.
Можно сделать вывод, что каждый из архитектурных подходов предоставляет свои определенные недостатки и преимущества. Монолитный подход даёт весьма неплохой старт, прощает ряд ошибок на начальных этапах:
всё можно достаточно быстро поправить и изменить. Но такие приложения обладают тенденцией увеличиваться в стоимости поддержки намного быстрее чем другие аналоги на базе иных архитектурных подходов. Причем, граница между модульным и монолитным приложением, с первого взгляда, редко видна, но интуитивно она понятна. С одной стороны, модульное приложение с самого начала состоит из модулей, каждый из которых обладает весьма строго описанным функционалом с определенными границами и его можно использовать в разнообразных ситуациях. С другой стороны, монолитное приложение может быть разработано из различного рода компонентов и классов, которые будут находиться в зависимости друг от друга и от данных,
которые имеют другие модули. Также помимо этого эти компоненты отчасти будут реализовывать функционал на тот момент уже существующий в иной части такого приложения, но несколько по отличной схеме. Сервис-
ориентированный подход на первых этапах довольно дорогой, но позволяет при правильном подходе сэкономить значительные финансовые вложения на дальнейших этапах. Но такой путь целесообразно выбирать лишь большим организациям, обладающим необходимым набором ресурсов в целях проведения тех или иных точных расчётов и планирования того, как именно в дальнейшем будет развиваться их разработка.
1.3. Анализ проблем функционирования и внедрения веб-приложений для организаций по ремонту, продаже и модернизации станочного оборудования
При рассмотрении проблем, которые могут возникнуть в функционировании веб-приложения для организации по ремонту, продаже и
17
модернизации станочного оборудования, обеспечивающего взаимодействие с клиентами, а также функционала, представленного сайтом, и пути их решения,
необходимо понимать, что стандартных проблем быть не может – всё очень индивидуально для каждого конкретного веб-сервиса сервиса [24].
Наличие высокого уровня конкуренции в современных рыночных условиях, а также учитывая специфику деятельности организации в данной сфере бизнеса – где каждый клиент имеет вес, и один клиент способен оказать существенное влияние на загрузку производственных мощностей организации и на объем потенциальной выручки. Качество обслуживания и предоставления услуг для клиентов – это один из самых значительных и ключевых факторов успеха любой организации, занимающейся ремонтом, продажей и модернизацией станочного оборудования. Хороший уровень постпродажного сервиса способствует формированию благоприятного имиджа организации, что означает рост количества лояльных клиентов и финансовых показателей, что, в
конечном счёте, и является первостепенной целью организации. Этим объясняется актуальность использования CRM (Customer Relationship
Management – управление взаимоотношениями с клиентами), то есть применение такой системы, которая будет направлена на построение устойчивого бизнеса с "клиенто-ориентированной" концепцией [14].
Чтобы понять, какие могут возникнуть проблемы в процессе взаимодействия с клиентом, важно рассмотреть стадии данного процесса[18]:
1) Поиск потенциальных клиентов.
В случае создания веб-приложения, который будет представлять собой информационный сайт, стадию поиска потенциальных клиентов можно будет назвать достаточно простой операцией. Это объясняется прежде всего тем, что из всего потока посетителей сайта, лишь некоторые будут взаимодействовать с его элементами (оставлять заявки на обратную связь, совершать заказ или же сами устанавливать связь с работниками организации по контактным данным на сайте или с помощью специализированных веб форм), вся полученная информация о таких людях, заинтересовавшихся предлагаемой продукцией
18
организации и ее услугами, будет результатом поиска потенциальных клиентов,
который по факту не нужно будет осуществлять персоналу самой организации.
Все они – это потенциальные клиенты. В базе данных сайта будут зафиксированы их контактные данные для дальнейшей работы с ними в соответствии с федеральным законодательством.
2) Контакт с потенциальным клиентом.
На данной стадии работы возможны следующие более менее стандартные сценарии взаимодействия менеджера с клиентом: телефонный звонок, e-mail
переписка, связь через социальные сети, Skype или месседжеры – всё будет зависеть от желаний и предпочтений потенциального клиента. Именно в этом будет заключаться одно из преимуществ разрабатываемого веб-приложения.
Клиент сможет сам выбрать способ общения, задать интересующий его вопрос,
сделать потенциальную заявку на обслуживание или модернизацию оборудования (если таковое ему потребуется для консультаций), дату и время контакта.
Так как у менеджеров стандартный 8-тии часовой рабочий день, и в нём нет круглосуточно консультирующих операторов, предварительный заказ контакта – это весьма рациональное решение данной стадии процесса.
Также с целью избежание нескольких повторных, к примеру, звонков,
писем, клиенту от разных сотрудников организации, на сайте в администраторском режиме сотрудники смогут отмечать заявки, которые были осуществлены и кем из сотрудников именно, а также оставить комментарий,
содержащий информацию о звонке (возможные пожелания клиента,
предварительную информацию, тип оборудования и т.д.) 3) Реализация достигнутых договоренностей.
Эта стадия предполагает, что после полученной консультации клиент либо совершит предварительный заказ на сайте, либо лично приедет для совершения заказа либо сотрудники организации сами выедут к клиенту на место постоянного пребывания его оборудования. Или же клиент,
самостоятельно ознакомившись с информацией на сайте, также самостоятельно
19
сделает на нём предварительный заказ или вышлет коммерческое предложение.
После чего следует лишь реализовать сотрудникам организации совершенный клиентов заказ.
Ситуацию совершения клиентом заказа на сайте можно также считать одним из способов взаимодействия с клиентом, поскольку клиент, заполняя форму заказа, обеспечит сохранение своих контактных данных в базе данных
[16]. В дальнейшем можно будет проводить анализ в разрезе каждого клиента при проведении определенных рекламных кампаний.
Также рассмотрим существующие бизнес-процессы в организации,
построим модель взаимодействия с клиентами AS-IS. Функциональная модель взаимодействия с клиентами, которая сейчас есть в организации, представлена на рисунках 1.5
Рисунок 1.5 - Родительская диаграмма бизнес-процессов
Целью формирования модели предметной области является выявление процесса осуществления обращения клиента и дальнейшая обработка
20
выполнения заказа. Декомпозиция данной модели представлена в приложении А.
1.4 Выводы по разделу
В первом разделе были рассмотрены роль, место и классификация веб-
приложений в организациях по ремонту, продаже и модернизации станочного оборудования. Также было уделено особое внимание CALS-технологии и её роли для предприятий станочного оборудования. Далее было рассмотрено понятие и задачи веб-приложения, а также его роль в процессе автоматизации взаимодействия между клиентами организации и самой организацией. При этом была рассмотрена степень автоматизации бизнес-процессов им уровень внедрения автоматизированных систем управления для технического обслуживания и ремонта оборудования, где было установлено, что в настоящее время уровень внедрения сильно отличается по отраслям бизнеса. А также были проанализированы основные программные продукты в данной сфере автоматизации и было установлено, что ни один из рассматриваемых продуктов не подходит для организации малого бизнеса.
При рассмотрении существующих подходов к проектированию и разработке веб-приложений для организаций по ремонту, продаже и модернизации станочного оборудования была рассмотрена структура обычного веб-приложения, а также модульные приложения клиентской и серверной части.
В ходе анализа проблем функционирования и внедрения веб-приложений для организаций по ремонту, продаже и модернизации станочного оборудования были выявлены основные проблемы, которых следует избегать и минимизировать вероятность их наступления для успешного функционирования веб-приложения.
21