Бизнес-план веб-студии. Автоматизация бизнес-процессов в Web-студии

ОПЫТ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССА НА ПРИМЕРЕ ПРЕДМЕТНОЙ ОБЛАСТИ «РАБОТА WEB-СТУДИИ»

Ермолаев Александр Геннадьевич 1 , Новикова Татьяна Борисовна 2 , Курзаева Любовь Викторовна 3
1 Магнитогорский государственный технический университет им. Носова, студент ФИПИб-12
2 Магнитогорский государственный технический университет им. Носова, кандидат педагогических наук, доцент ИЭиАС
3 Магнитогорский государственный технический университет им. Носова, кандидат педагогических наук, доцент ИЭиАС

BUSINESS PROCESS MODELING «WORK OF WEB STUDIO»

Ermolaev Alexander Gennadevich 1 , Novikova Tatyana Borisovna 2 , Kurzaeva Lyubov Viktorovna 3
1 Magnitogorsk state technical university of Nosov, student FIPIB-12
2 Magnitogorsk state technical university of Nosov, candidate of pedagogical sciences, associate professor
3 Magnitogorsk state technical university of Nosov, candidate of pedagogical sciences, associate professor

Библиографическая ссылка на статью:
Ермолаев А.Г., Новикова Т.Б., Курзаева Л.В. Опыт моделирования бизнес-процесса на примере предметной области «Работа web-студии» // Современные научные исследования и инновации. 2016. № 1 [Электронный ресурс]..03.2019).

Информационный прогресс, начавшийся в конце XX – начале XXI века стал результатом стремительного развития web технологий нашей стране. При стремительно начавшейся компьютеризации, появился и интерес к глобальной сети Интернет. По прошествии некоторого времени, “всемирная паутина” и вовсе перестала быть только предметом развлечения . На данный момент Интернет является плацдармом для эффективного продвижения своего продукта. Как известно, спрос порождает предложение, и сфера Интернет рекламы не исключение. Сейчас почти все доверяют рекламу своего продукта web студиям. Подобные студии занимаются разработкой разных видов сайтов, которые в последствии используются как инструмент для привлечения новых клиентов .
Однако предприятия, предоставляющие услуги создания сайтов, имеют множества недостатков. Одна из самых распространенных проблем у подобных компаний – это плохая организация баз данных клиентов. Этим и обуславливается актуальность данной работы .
Целью данной работы является поиск наиболее подходящих вариантов решения ранее поставленных проблем.
Объектом данного исследования является организация, предоставляющая услуги создания и разработки сайтов .
Рассматриваемая организация – это веб-студия, работающая как в Магнитогорске, так и удаленно.
Предприятие берется за разработку проектов разной величины, начиная с мелких сайтов- визиток и заканчивая огромными порталами .
Краткая характеристика компании
Компания организована в Магнитогорске в 2012 году.

Здание офиса является рабочим местом для всех членов команды. Заказы компания может принимать как по электронной почте, так и после контакта с клиентом непосредственно в офисе. Клиент имеет право на доработку проекта, после аргументированных претензий. Компания работает по 50% предоплате . После того, как заказчик одобряет проект, происходит передача сайта и оставшейся суммы денег.
Правовая форма
С точки зрения организационно-правовой формы, компания является обществом с ограниченной ответственностью.
Миссия предприятия
Компания стремится монополизировать рынок разработки сайтов под индивидуальные заказы клиентов города Магнитогорска за счет качества предоставляемых услуг и приемлемых цен, сроков разработки. Так же предполагается расширить границы компании до Челябинской области, увеличить долю клиентов, пришедших по онлайн заявке.
Основные цели предприятия
- увеличение клиентской базы
- наращения портфолио
- улучшение качества предоставляемых услуг
- увеличение прибыли
Одной из самых важных целей предприятия является улучшение качества предоставляемых услуг. Так как основной бизнес процесс – это процесс создания сайта, то основные силы следует направить на его оптимизацию и модернизацию .

Диаграмма Исикавы (другое название «Рыбья кость»). Подобная модель позволяет определить наиболее существенные причинно-следственные взаимосвязи между факторами и последствиями в исследуемой предметной области
Предмет деятельности предприятия
- оформление и выполнение заказов на разработку сайта
- продвижение сайта
- модернизация существующих сайта
- создание уникального дизайна сайта
- верстка макетов
- написание статей
Основной бизнес процесс (процесс создания сайта) можно представить в разных вариантах и нотациях. Основные это IDEF0, DFD, eEPC.
Модель IDEF0 отображает непосредственно бизнес процесс. IDEF0 использует описание типа «черный ящик» который имеет вход, выход, управление и механизм
Data Flow Diagrams (DFD) - диаграммы потоков данных представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами .
Extended event driven process chain (eEPC) представляет собой блоки, которые образуют цепь событий. Подобная цепь отражает алгоритм ведения бизнес процесса.

Предприятие так же сотрудничает с внешними компаниями по предоставлению различных видов услуг (таких как копирайтинг, рерайтинг, верстка, доработка модулей для CMS и др.)
Основные виды расходов
- затраты на зарплату персоналу
- аренда помещений и оплата коммунальных услуг
- затраты на содержание сервера
- затраты на рекламу
- затраты на техническое и ПО
Основные документы (входные, выходные, внутренние)
Входные:
- заказ на создание сайта
Выходные:
- договор на создание сайта
- руководство пользователя
Внутренние:
- техническое задание
- план графика работы
Бизнес-процесс инициируется поступившей заявкой в систему. Она рассматривается руководителем фирмы и главным менеджером, после чего, в зависимости от решения руководства утверждается, либо возвращается обратно заказчику в виде отрицательного ответа . Далее составляется договор на создание сайта, в котором отражаются сроки сдачи проекта, оплата и прочие детали. После договора формируется техническое задание на основе пожеланий клиента . Как только техническое задание создано, персонал получает документ план график. Он отражает расписание работы и задачи, которые необходимо выполнить каждому отделу . Далее идет непосредственно процесс работы персонала. Когда менеджер получает от отделов результаты работ, начинается формирование отчетности.
В процессе исследования работы веб-студии были найдены проблемные места, из-за которых организация не может работать на полную мощность. Однако стоит отметить, что не для всех проблем есть полноценные решения. Список выявленных узких мест выглядит следующим образом:
- влияние человеческого фактора
- не всегда новое оборудование и программное обеспечение
- слишком большая конкуренция
Для решения выявленных проблем, были разработаны следующие варианты:
1. Как известно, что проблему человеческого фактора полностью решить невозможно. Однако сократить последствия после ошибки человека можно наняв более квалифицированный персонал
2. Проблема оборудования решается очень просто – покупкой нового оборудования. Аналогично и с программным обеспечением. Если компания не может позволить себе новейшее ПО, то можно попробовать часть ПО заменить на бесплатное.
3. Проблему конкуренции, так же как и проблему человеческого фактора, решить очень трудно. Единственное решение – это улучшить качество собственной продукции, либо понизить цены на товар.

Библиографический список

1. Гаврилова И.В., Новикова Т.Б., Петеляк В.Е., Назарова О.Б., Агдавлетова А.М. Совершенствование методов построения причинно-следственных диаграмм для решения задач управления в организационных системах / И.В. Гаврилова, Т.Б. Новикова, В.Е. Петеляк, О.Б. Назарова, А.М. Агдавлетова. -
   Фундаментальные исследования . 2015. № 8-2 . С. 247-251.
2. Давлеткиреева Л.З., Назарова О.Б. Методические механизмы эффективности подготовки ИТ-специальностов вуза при переходе от процесса обучения к учению с применением комплекса профессионально-направленных задач//Современные информационные технологии и ИТ-образование. – 2011. – № 7. С. 133-140.
3. Давлеткиреева Л.З., Новикова Т.Б., Курзаева Л.В., Лактионова Ю.С., Подкользина Л.В. Управление технологической архитектурой организации на основе усовершенствованного метода Enterprise Architecture Planning / Л.З. Давлеткиреева, Т.Б. Новикова, Л.В. Курзаева, Ю.С. Лактионова, Л.В. Подкользина. – Фундаментальные исследования . 2015. № 8-2 . С. 252-256.
4. Курзаева Л.В., Новикова Т.Б., Давлеткиреева Л.З., Назарова О.Б., Белоусова И.Д. Совершенствование методики построения моделей событийно-управляемого процесса для постановки задач управления в социальных и экономических системах / Л.В.
   Курзаева, Т.Б. Новикова, Л.З. Давлеткиреева, О.Б. Назарова, И.Д. Белоусова. -
   Фундаментальные исследования . 2015. № 8-2 . С. 297-302.
5. Масленникова О.Е. ТИПОВОЙ ПРОЕКТ ВНЕДРЕНИЯ КОРПОРАТИВНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ НА КРУПНОЕ ПРОМЫШЛЕННОЕ ПРЕДПРИЯТИЕ / О.Е. Масленникова. – Актуальные проблемы современной науки, техники и образования. 2015. Т. 2. № 1. С. 149-152.
6. Масленникова О.Е., Белоусова И.Д. КОМПЛЕКС ПРЕЗЕНТАЦИЙ ПО ДИСЦИПЛИНЕ «ИНФОРМАЦИОННЫЕ СИСТЕМЫ» / О.Е. Масленникова, И.Д. Белоусова. – Хроники объединенного фонда электронных ресурсов Наука и образование. 2014. Т. 1. № 2 (57). С. 21.
7. Масленникова О.Е., Назарова О.Б. РОЛЬ И МЕСТО ПРОЕКТНОЙ РАБОТЫ СТУДЕНТОВ В ИХ ПРОФЕССИОНАЛЬНОМ СТАНОВЛЕНИИ / О.Е. Масленникова, О.Б. Назарова. – В сборнике: Новые информационные технологии в образовании. материалы VIII междунар. науч.-практ. конф.. Рос. гос. проф.-пед. ун-т. Екатеринбург, 2015. С. 470-474.
8. Масленникова О.Е. , Савва Л.И. Критериально-оценочный аппарат и методика подготовки студента к межличностному познанию средствами автодидактики: Учеб.-метод. пособие. -Магнитогорск: МаГУ, 2005. -60 с.
9. Масленникова О.Е. , Чусавитина Г.Н. Мастер-класс как форма взаимодействия работодателя с будущими ИТ-специалистами//Разработка инновационных механизмов повышения конкурентоспособности выпускников ИТ-специальностей вуза в условиях монопромышленного города: cб. ст./под ред. Г.Н. Чусавитиной, Л.З. Давлеткиреевой. Магнитогорск: МаГУ, 2012. С. 75-85.
10. Масленникова, О. Е. Основы искусственного интеллекта: учеб. пособие/ О. Е. Масленникова , И. В. Гаврилова . -2-е изд., стер. -М.: ФЛИНТА, 2013. -282 c.
11. Масленникова, О.Е. Информационная система управления как ядро информационной инфраструктуры современного образовательного учреждения [Текст]/ О.Е. Масленникова // Вестник компьютерных и информационных технологий . -М., 2010. -№ 8. -С. 47-51
12. Масленникова, О.Е. Методика формирования компетенций ИТ-специалиста в области информационных систем по образовательной программе «Прикладная информатика»/ О.Е. Масленникова , О.Б. Назарова // Гуманитарные научные исследования . -Декабрь 2013. -№ 12 . URL:http://human.snauka.ru/2013/12/5375 (дата обращения: 25.12.2013).
13. Назарова О.Б. Разработка региональной модели индивидуальной траектории профессионального развития бакалавров и магистров для реализации стадий создания автоматизированных систем как научная проблема// Современные информационные технологии и ИТ-образование: сб. избранных трудов IX Международн. науч.-практич. конф./ под ред. Проф. В.А. Сухомлина.- М.: ИНТУИТ.РУ, 2014. – 957 с. – 978-5-9556-0165-6. – С. 639-664.
14. Назарова О.Б., Масленникова О.Е. Роль и место проектной работы студентов в их профессиональном становлении//Новые информационные технологии в образовании: Материалы VII Международ. науч.-практ. конф. (Екатеринбург, 10-13 марта2015 г.). Екатеринбург: ФГАОУ ВПО «Рос.гос.проф..-пед.ун-т», 2015. – С. 470-475. – Библиограф. с. 475.
15. Назарова О.Б., Масленникова О.Е., Новикова Т.Б., Давлеткиреева Л.З.
    Преемственность дисциплин кафедры по направлению «Прикладная информатика» и межпредметная координация как фактор повышения эффективности образовательного процесса / О.Б. Назарова, О.Е. Масленникова, Т.Б. Новикова, Л.З. Давлеткиреева. -
    Актуальные проблемы современной науки, техники и образования . 2015. Т. 2. № 1 . С. 145-148.
16. Назарова О.Б., Давлеткиреева Л.З., Масленникова О.Е., Пролозова Н.О. Сопровождение корпоративных информационных систем / О.Б. Назарова , Л.З. Давлеткиреева , О.Е. Масленникова , Н.О. Пролозова . -Магнитогорск: МаГУ, 2013. -220 с.
17. Назарова, О.Б., Масленникова, О.Е. Разработка реляционных баз данных с использованием CASE-средства ALL Fusion Data Modeler: учеб. Пособие / О.Б. Назарова , О.Е. Масленникова . -Москва: Изд-во «ФЛИНТА», 2013. -74 с.. -Библиогр.: с. 52. -500 экз.. -ISBN 978-5-9765-1601-4
18. Назарова, О.Б., Масленникова, О.Е., Давлеткиреева, Л.З. Формирование компетенций специалиста в области информационных систем с привлечением вендоров / О.Б. Назарова , О.Е. Масленникова , Л.З. Давлеткиреева // Прикладная информатика . -2013. -№ 2(44). -С. 49-56. -Библиогр.: с.56, ISSN 1993-8314
19. Новикова Т.Б., Курзаева Л.В., Петеляк В.Е., Масленникова О.Е., Белоусова И.Д. Описание управления бизнес-процессами предприятия на основе методологии IDEF0: трудности разработки, рекомендации по совершенствованию построения диаграмм / Т.Б. Новикова, Л.В. Курзаева, В.Е. Петеляк, О.Е. Масленникова, И.Д. Белоусова. -
    Фундаментальные исследования . 2015. № 8-2 . С. 318-322.
20. Петеляк В.Е. О некоторых системных недостатках программы подготовки инженерно-технических кадров в рамках объявленной политики модернизации страны / В.Е. Петеляк //Современные проблемы науки и образования: материалы XLIX Внутривузовской науч.конф. преподавателей МаГУ; Министерство образования и науки Российской Федерации; ГОУ ВПО “Магнитогорский государственный университет”/под ред. З. М. Уметбаева, П. Ю. Романова, Т. В. Саляевой. Магнитогорск: изд-во Магнитогорского гос. у-та, 2011. -С. 259-260
21. Петеляк В.Е., Новикова Т.Б., Масленникова О.Е., Махмутова М.В., Агдавлетова А.М. Data Flow Diagramming: особенности построения моделей описания управления потоками данных в организационных системах / В.Е. Петеляк, Т.Б. Новикова, О.Е. Масленникова, М.В. Махмутова, А.М. Агдавлетова. – Фундаментальные исследования . 2015. № 8-2 . С. 323-327.
22. Требования к выпускной квалификационной работе студентов специальности 080801 «Прикладная информатика (в экономике)» (методические рекомендации) /

План презентации Почему необходимо моделирование бизнес-процессов веб-студии. Опыт «WebProfy»: рабочая схема бизнес-процесса создания сайта (поэтапное рассмотрение). Основные ошибки начинающих веб-студий. Бизнес-процесс – логичный, последовательный, взаимосвязанный набор мероприятий, потребляющий ресурсы, формирующий ценность, создающий результат.

Почему необходимо моделировать бизнес-процессы веб-студии? Не бывает двух одинаковых проектов! (аксиома) Обеспечить прозрачность и предсказуемость проекта для Исполнителя и Заказчика – Цели, задачи проекта – Участники, коммуникации – Этапы работ, контрольные точки – Сроки реализации – Результат Алхимия? Нет! Рецепт – оптимизация бизнес-процесса.

Этап 2. Проектирование продукта Подготовка Брифа Подготовка Технического Задания Подготовка Спецификаций – формирование требования по дизайну – определение перечня и сбор исходных материалов – структура сайта – инфоблоки (названия, свойства, логика работы) – сервисы (печать, комментарии, отзывы и т.д.) – сетки страниц – регламентация правил формирования файла выгрузки Согласованный и подписанные Бриф, ТЗ, Спецификации

Этап 3. Дизайн Дизайн-концепция главной страницы Дизайн типовой внутренней страницы Дизайн экранных форм (каталог, корзина, личный кабинет) – разработка макета – презентация заказчику – формирование листа замечаний, реализация замечаний – утверждение макета – порядок работ – аналогичен Акт сдачи-приемки работ по этапу дизайна

Этап 4. Верстка Дизайн-концепция главной страницы Открытие тестовой площадки Верстка главной страницы, типовой внутренней страницы и экранных форм – Демонстрация заказчику – Формирование листа замечаний, реализация замечаний – Утверждение верстки Создание прототипа и шаблонов Акт сдачи-приемки работ по этапу верстки

Этап 5. Программирование Программирование стандартного функционала Программирование дополнительных модулей Внутреннее тестирование Тестирование модели заказчиком – параллельно – запрос файла выгрузки – параллельно – тестовая интеграция – первичное наполнение, исправление выявленных несоответствий с ТЗ) – Демонстрация заказчику – Формирование заказчиком bag-list – Внесение правок заказчиком – Утверждение программной части Акт сдачи-приемки работ по этапу программирования

Основные ошибки молодых компаний 2. Приоритет «картинки» над дизайном – Неверное выявление целей и задач – Размытое представление о целевой аудитории – Экономия времени на погружение в предметную область – Прямое копирование чужих работ – Неверное расставление приоритетов

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

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

Наша Студия всегда располагалась в российской «силиконовой долине» - Зеленограде. У нас были сильные программисты, а значит мы могли легко получать и выполнять такие заказы. Было решёно - это наш шанс!

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

Какая гадость эта ваша веб-интеграция

Обеспечить обмен данными между двумя системами несложно. Но наши первые несколько лет работы в новом качестве были болезненными и обошлись недёшево.

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

Мы не сдавались, и, словно мышки из анекдота, «кололись, плакали, но упорно продолжали грызть кактус».

Перед тем как приступить

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

Для нас, программистов, любая разработка несложных сайтов сводится к такой модели:

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

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

Шаг 1. Цели и задачи

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

Типичный пример: Сайт должен быть интегрирован с билетной системой ProfTicket.

и стараемся в таких случаях добиться большей однозначности формулировки:

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

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

Шаг 2. Бизнес-процессы и протокол взаимодействия

Теперь нужно решить, как системы должны взаимодействовать для выполнения той или иной задачи. Продолжим строить аналогии с билетной системой. Кстати, речь идет о совершенно реальном проекте: в 2013 году мы помогли компании «Дилявер» открыть сервис заказа билетов ShowMart.Ru . Для выполнения бронирования билета необходимо ответить на несколько вопросов:

• Какое мероприятие выбрал покупатель?
• Какой сеанс (сочетание даты и времени) был выбран?
• Какие места (номер сектора, ряд и кресла) были выбраны?
• Не были ли проданы эти места другому покупателю ранее?
• Не находятся ли данные места в резерве, иными словами, не происходит ли оформление покупки этих мест другим покупателем прямо сейчас?
• И так далее...

Любое взаимодействие между системами сводится к структуре «запрос - ответ». Запрос отправляет сторона, которой необходимо получить данные (клиент), а ответ - сторона, у которой эти данные есть (сервер).

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

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

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

Шаг 3. Регламент принятия решений и медиаторы

Даже в самом простом проекте веб-интеграции принимают участие как минимум три стороны:

1. Заказчик.
2. Владелец системы А (например, 1С-программист в штате клиента).
3. Владелец системы Б (собственно, мы - веб-программисты).

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

Важно подумать о том, как будут разрешаться спорные ситуации до того, как они появятся. Это непростая тема, но необходимо договориться хотя бы о фундаментальных моментах, например:

• Чем стороны будут руководствоваться при принятии решения: быстродействием, вопросами безопасности данных или минимальными изменениями в 1С?
• Кто будет ответственной стороной, принимающей последнее решение, в том случае, если владельцы систем не могут договориться между собой?

На первый взгляд кажется, что ответ на последний вопрос очевиден: заказчик - кому же еще принимать окончательные решения? Однако, это не всегда так.

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

Шаг 4. Стандарт и формат обмена данными

Теперь необходимо договориться о том, на основе какого стандарта и каким способом мы будем осуществлять обмен данными между системами.

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

SOAP расшифровывается, как Simple Object Access Protocol. Если дословно переводить с английского, то получится «Простой Протокол Доступа к Объектам». Этот протокол действительно является одним из самых простых и часто используемых при построении веб-проектов. SOAP представляет собой протокол обмена структурированными XML-сообщениями.

Для того чтобы системы использовали единый регламент построения запросов и ответов, используются файлы c описанием такого регламента, составленным на основе стандарта WSDL (от англ. Web Service Description Language - Язык Описания Веб-Сервисов).

SOAP является расширением протокола XML-RPC, и это большой плюс протокола. XML широко распространен, и с форматом XML-Schema хотя бы поверхностно знакомо огромное число специалистов.

Этот же факт является и самым большим минусом SOAP. XML - объёмный формат и с ростом количества данных, которыми обмениваются системы, растет количество передаваемого трафика. С ростом последнего увеличивается время, необходимое на обработку запросов и формирование ответов на них. Всё это делает связку WSDL/SOAP практически непригодной для использования в системах с огромными объёмами плохо структурированных данных - в так называемых Big Data-системах.

SOAP станет отличным выбором, например, для решения задач интеграции интернет-магазина с небольшим ассортиментом со складской системой 1С. В её стандартной поставке предусмотрена поддержка этого протокола, и всё, что останется сделать, подготовить WSDL-описания.

REST (расшифровка аббревиатуры в данном случае нам ничего не даст, поэтому мы ей пренебрежем) - это протокол вызова удаленной процедуры с помощью обычного HTTP-запроса. Да-да, с помощью тех самых методов GET и POST из учебников Тима О’Райли.

За каждый метод в REST отвечает не отдельно взятая запись в файле WSDL, а URL. К примеру, метод для получения сведений о пользователе будет иметь вид - http://example.com/rest/user. А метод создания нового пользователя - http://example.com/rest/user/create.

Для передачи параметров в REST можно использовать тело запроса, а для описания ошибок - статусные заголовки HTTP. Всё максимально просто и не требует использования дополнительных протоколов. REST гораздо примитивнее SOAP. Именно это делает его отличным выбором, когда нужно обмениваться большим объёмом данных и делать это часто.

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

Иногда приходится использовать комбинации нескольких методов и протоколов взаимодействия.

В 1С есть собственный формат CommerceML - XML для передачи коммерческой информации, чаще всего таким способом передаются каталоги товаров.

Этот формат разработан специалистами фирм 1С и Extra.RU. Им помогали друзья из московского офиса Microsoft.

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

Иногда у клиента нет выделенного внешнего сервера для взаимодействия. Тогда мы заводим отдельную папку прямо на сервере хостинга для того, чтобы 1С выгружала туда свои файлы. Там они распознаются нашими скриптами по расписанию.

В случаях когда нужно постоянно поддерживать данные в актуальном состоянии, мы можем связать Rest API и передачу XML вместе. Тогда 1С будет отправлять XML напрямую на сервер, используя стандартные POST-запросы.

Шаг 5. Безопасность данных

Чаще всего там, где возникает необходимость в интеграции, есть объекты коммерческой тайны или персональные данные. Работа с ними после недавних изменений в законодательстве теперь заслуживает отдельной статьи.

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

Вариантов защиты много. Мы рассмотрим только некоторые из них.

Протокол HTTP - самый распространенный и самый незащищенный. Данные по нему передаются в незашифрованном виде. HTTPS - это разновидность http-протокола, поддерживающая шифрование с использованием сертификатов SSL или TCL.

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

Окно предупреждения пользователя о недостоверном соединении Для того чтобы сертификат считался доверенным, его необходимо заказывать у организации, занимающейся сертификацией - центра сертификации. Таких учреждений много. Работая над проектами европейских заказчиков, мы предпочитаем пользоваться услугами одного из двух крупнейших игроков на рынке SSL-сертификации - Thawte или Verisign. В России работаем с Ру-центром. Их значки можно часто видеть на сайтах, где подразумевается оплата или работа с персональными данными.

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

Чтобы злоумышленники не смогли перехватить пароли, «представляться» системам лучше в шифрованном виде, т.е. HTTP-basic авторизацию надо использовать совместно с SSL-шифрованием.

Если система не слишком сложна и у серверов взаимодействующих систем есть определенные и неизменные IP-адреса, можно предоставлять доступ к обмену данными только для этих IP-адресов.

Этот вариант прост в реализации и поэтому широко распространен. Но иногда он приводит к внезапным проблемам с доступом.

Шаг 6. Техническое задание

У вас могут быть превосходные отношения с заказчиком или его 1С-программистами, но «дружба дружбой, а табачок врозь». Мы настоятельно рекомендуем зафиксировать договоренности по всем описанным шагам письменно.

Поучительный пример из собственного опыта: Нам предстояло сделать сложную интеграцию «1С:Предприятия» заказчика с используемым интернет-магазином. На встрече с 1С-программистами мы договорились о том, что они подготовят веб-сервисы на своей стороне, к которым веб-программисты Студии будут впоследствии обращаться.

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

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

В приведённом примере нам повезло - 1С-программисты оказались ребятами порядочными и подтвердили перед своим руководством нашу правоту. Но повезет ли так же в следующий раз?

Вы можете работать по гибким методологиям, использовать классический «водопад» или применять гибридную методику. Это не важно, также как и формат и объем ТЗ. Важно только то, что все договоренности должны быть так или иначе зафиксированы.

Шаг 7. Реализация

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

Чтобы разработка шла как можно более гладко, избегайте деления на «ваших» и «наших». Наоборот, сделайте всё для формирования единой команды из разработчиков внешней информационной системы и ваших программистов.

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

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

Работая с третьей стороной, придется заниматься тестированием не только «на выходе», но и «на входе».

Пример из собственной практики: программист CRM-системы отчитался, что веб-сервис, необходимый для выполнения работы завершен. Руководитель проекта сформировал задачу веб-программисту и выставил ее, сопроводив ссылкой на этот веб-сервис. На следующий день веб-программист в точном соответствии с графиком приступил к выполнению задачи и столкнулся с тем, что веб-сервис не работает. Задача возвращается CRM-программисту. Время веб-программиста, руководителя проекта и деньги заказчика потрачены впустую. Все снова ждут готовности нужного веб-сервиса.

Раньше всё зависело только от вашей команды, и сформулированная задача сразу выставлялась программисту. Теперь же придётся сначала убедиться в том, что компоненты для решения задачи, выполненные третьей стороной, действительно работают.

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

Чем быстрее обнаружится, в каком месте системы и что именно «полетело», тем меньшими будут затраты на её поддержку, и тем выше будет прибыль. Поэтому не экономьте на покрытии кода тестами.

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

Шаг 8. Отказоустойчивость

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

Некоторые из проектов, выполненных нами, могут потерять от $35 000 до $70 000 в случае суточного простоя. Это заставляет дополнительно задумываться о мероприятиях повышения отказоустойчивости всей системы.

• Резервное копирование. Все это прописывают в ТЗ и договорах. Но давайте будем честны, вы всегда проверяете, действительно ли хостер или разработчик настроил процедуры резервного копирования в соответствии с договоренностями? Чаще всего это выясняется тогда, когда беда уже произошла.
• Нагрузочное тестирование. На какую посещаемость и пиковую нагрузку рассчитывает заказчик? Умножьте эту цифру хотя бы на 2,5 и сделайте синтетические нагрузочные тесты. Тестировать нужно не только сайт, но и те системы, с которыми взаимодействует проект.
• Сезонность. Знайте сезонность бизнеса своего заказчика. Посещаемость сайта сети кинотеатров, который мы сделали и поддерживаем, в новогодние праздники возрастает в 2-3 раза. В этом проекте мы начинаем подготовку к Новому году в начале ноября.
• Готовность к «откату». Вы работаете в команде, и это придется учитывать. Будьте готовы к тому, что ваши новые функции могут нарушить нормальную работу внешней системы и изменения придется быстро «откатить» назад. Несмотря на нагрузочное тестирование, внешние системы иногда выходят из строя по независящим от вас причинам. Вы должны быть готовы продолжить работу, отключив на время совместный функционал. Например, во время аварии сервиса покупки билетов вместо процесса оформления заказа мы показываем сообщение с извинениями, но сам сайт продолжает свою работу.

Шаг 9. Логирование и мониторинг

Не забудьте учесть в сроках и бюджете проекта затраты на создание системы логирования. Мы довольно долго набивали шишки в этом месте.

Это объективный инструмент, с помощью которого можно будет восстановить хронологию событий, поможет не только сохранить нервы, но и защитит в случае судебных разбирательств. Поэтому готовую систему важно «обвешать» индикаторами и датчиками.

В Студии мы стараемся сделать всё так, чтобы о выходе из строя сайта или его части узнавать не из телефонного разговора с разъярённым клиентом, а при помощи собственных систем мониторинга.

Мы не станем подробно затрагивать этот процесс и, может быть, посвятим этому отдельную статью, но для тех, кто плохо знаком с этими темами, советуем начать с гугления терминов Pinba, Zabbix и Munin.

Шаг 10. Документирование

Договоритесь о том, в каком виде будет вестись проектная документация, и постарайтесь держать её в актуальном состоянии.

Это поможет избежать ситуаций, когда для устранения неполадок приходится знакомиться со всем программным кодом. Если даже программист, изначально разработавший всё это, через полгода уже не вспомнит, что и как должно работать, стоит ли говорить о новых разработчиках?

Совет самый простой по смыслу и самый сложный по соблюдению. Мы в Студии стараемся это делать примерно так:

• Договорились о формате ведения и месте хранения проектной документации.
• Составили перечень документов, входящих в понятие «проектная документация». Как правило это несколько документов, включая карту бизнес-процессов, описание серверной архитектуры, наше ТЗ, документация на API внешней системы, и т.д.
• Назначили ответственного за актуальность документации. Обычно это руководитель проекта.
• Назначили периодичность проверки документации.

Всё! Теперь ответственный время от времени делает выборочную или сплошную, это уже кому как нравится, проверку актуальности документов. Или не делает... и понимает, что может огрести за это в любой момент.

Заключение

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

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

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

Наш арт-директор Саша Котов считает, что мы «маемся дурью», и это никто читать не будет:-)

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

* В расчетах используются средние данные по России

Содержание своего интернет-портала – дело достаточно сложное и хлопотное. При этом сегодня свой сайт (или хотя бы страница в социальной сети) – очень эффективный инструмент продвижения своих товаров или услуг, сайт позволяет напрямую контактировать с потребителями, осуществлять online-продажи и заниматься ещё целым перечнем задач, которые через интернет решаются наиболее оперативно, экономически выгодно и эффективно. В связи со всем этим потребность в создании сайта велика у любой компании (хотя, конечно, есть сферы бизнеса, где отсутствие сайта не критично), но далеко не каждая фирма в состоянии заниматься разработкой и поддержкой созданного интернет-портала своими силами. Обычно эти процессы передаются на аутсорсинг, и в этой статье будет рассмотрена возможность открытия своей студии web-дизайна. Многими считается это направление очень выгодным и перспективным, но здесь существует немало своих особенностей, которые обязательно нужно учитывать перед стартом.

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

Чтобы начать свою работу, нужно зарегистрироваться как субъект предпринимательской деятельности, тут можно оформиться и как индивидуальный предприниматель, потому что тогда можно будет решить все бюрократические вопросы в кратчайшие сроки и с минимальными затратами сил и денег. Если есть необходимость в регистрации юридического лица, то предпочтительной формой является общество с ограниченной ответственностью, потому что в этом случае, как и в случае с индивидуальным предпринимательством, будет доступна упрощённая система налогообложения, предполагающая перечисление в пользу государства не более 6% от доходов или 15% от операционной прибыли в качестве налогов. Непосредственно дизайнерская деятельность подпадает под определение (ОКПД 2) 74.1 Услуги по специализированному дизайну, но в своей работе могут потребоваться и другие классификаторы. Сама работа не потребует получение дополнительных разрешений или лицензий, только если компания не предполагает заниматься хостинговой деятельностью или работать в сфере информационной безопасности.

Актуальный вопрос – ситуация на рынке. Да, на настоящий момент нельзя сказать, что рынок страдает от нехватки предложения, обычно потребитель имеет возможность выбирать среди множества студий, потому что web-дизайном пытается заниматься значительный процент выпускников, освоивших программирование и/или дизайн. На первый взгляд всё действительно кажется очень простым – достаточно обучиться какой-либо из этих специальностей, найти себе команду и единомышленников, которые будут заниматься другими аспектами деятельности, после чего дать о себе рекламу и в итоге заниматься интересным делом и получать за это деньги. Но если отбросить даже вопрос технического плана (непосредственно само программирование и всё сопутствующее), то нельзя забывать о том, что дизайнерская работа – процесс исключительно творческий, и тут даже хорошего образования может быть недостаточно, потому что нужен также ещё и художественный талант. А также умение работать в строгом соответствии с требованиями клиента, то есть уметь не только создавать что-то новое, творить, заниматься творчеством, но и наоборот – сдерживать свой талант, выполняя именно то, что задали. Всё-таки так могут делать только профессионалы своего дела, и найти их бывает очень непросто. И ко всему прочему – программирование, специалист соответствующего профиля должен уметь справляться с задачей любой сложности. Именно поэтому услуги web-дизайна хорошо оплачиваются – ведь это непростой процесс, требующий нетривиального подхода зачастую. Отсюда можно сделать вывод, что если на старте действительно есть грамотные и опытные люди, то можно рассчитывать на выигрыш в конкурентной борьбе даже с ведущими компаниями на местном рынке. В ином случае даже при больших инвестициях, если при этом набрать неправильную команду, можно быстро обанкротиться – здесь клиент всё-таки в первую очередь ценит качество, а не низкую цену. То есть несмотря на достаточно большое количество конкурентов, выйти на рынок шанс есть у каждого новичка, главное уметь правильно использовать свои сильные стороны и слабые стороны конкурентов. SWOT-анализ здесь перед стартом может дать ответы на многие вопросы и сконцентрировать внимание на наиболее актуальных проблемах. Однако отметить стоит ещё раз – во многих случаях определяющим фактором становятся люди, которые и будут задействованы в работе.

В данном направлении бизнеса не всегда целесообразно арендовать свой офис. Особенно на первых порах. Забегая немного вперёд, отметим, что значительная часть сотрудников будет работать удалённо (фрилансеры), поэтому иногда нет смысла находить помещение, заниматься наймом руководителей, которые просто следят за ситуацией в офисе, и проводить прочую администраторскую волокиту, которая никоим образом не влияет на получение прибыли, а зачастую наоборот влечёт за собой дополнительные траты. Конечно, своё представительство где-нибудь в центре города, в бизнес-центре может быть очень привлекательным для клиента, добавлять престижа, но чаще всего – это просто ненужное дополнение. Конечно, если располагать студию фактически на дому, то придётся в любом случае побеспокоиться о месте, где будут проходить переговоры с клиентами. Это может быть и нейтральная территория, например, какое-нибудь заведение питания, некоторые конторы и вовсе приглашают своих клиентов на дом (но это возможно в том случае, если нет расчёта сотрудничать с солидными организациями) либо же арендуют офисное помещение буквально только на время переговоров – то есть на час. В этом случае придётся найти место, которое можно снимать с некоторой периодичностью. Однако говорить и том, что офис вообще не нужен, нельзя, при некоторых форматах работы, в зависимости от того, как организован рабочий процесс, аренда своего помещения, где постоянно находятся сотрудники, может быть необходима. Это как раз касается случае, когда компания предлагает широкий спектр услуг, она постоянно загружена работой и содержит немалый штат сотрудников. В этом случае достаточно часто требуется содержать своё представительство, хотя определённая часть людей так и продолжает работать удалённо. В целом можно сказать так – попробовать открыть свою web-студию можно и на дому, однако нельзя исключать возможной необходимости в дальнейшем аренды уже отдельного офисного помещения. Которое тогда уже действительно лучше искать в деловых кварталах, чтобы максимально большое количество потребителей могло приехать в офис за небольшой промежуток времени. Стоимость аренды помещения зависит от большого количества факторов, но местоположение обычно является наиболее существенным. Также, если отрывается представительство, нужно рассчитывать на проведение хотя бы косметического ремонта и закупку соответствующего оборудования – мебели и техники. Содержание офиса также предполагает ежемесячную оплату коммунальных платежей, в которые помимо основных входит оплата интернета. Отдельной статьёй расходов становится закупка соответствующего программного обеспечения, которое в своих корпоративных версиях может стоить несколько десятков тысяч рублей.

Готовые идеи для вашего бизнеса

В самом начале своей работы, только если в команде ненароком не оказался именитый дизайнер со своей клиентской базой, стоит всё же сконцентрироваться в первую очередь на предоставлении услуг в каком-либо относительно узком направлении. То есть попытаться найти нишу, которая не слишком охвачена конкурентами. Это, к примеру, может быть ориентация только на небольшие фирмы или разработка исключительно сайтов-визиток, или работа с предприятиями, которые заняты только в определённой области. Пытаться сходу соперничать и отбирать клиентов у крупных студий не стоит. Также нет смысла начинать работу, предлагая свои услуги по географически большому региону. То есть лучше работать с потребителями услуг в своём городе, в крайнем случае – в области, но никак не в нескольких субъектах РФ одновременно. Итак, студия web-дизайна теоретически может заниматься предоставлением не только дизайнерских, но и иных услуг:

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

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

SEO, SMM, SMO. Наиболее прогрессивные и современные решения в области содержания интернет-порталов. Позволяют «продвигать» сайт всеми возможными способами – от размещения в топе запросов поисковых машин (SEO) до поиска клиентов в социальных сетях (SMM) и привлечения трафика из соцсетей на нужный сайт (SMO). Это уже маркетинговые услуги, правда, очень востребованные на рынке.

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

Таким образом, предприниматель имеет широкий спектр возможностей, причём некоторые из направлений можно рассматривать как вариант развития, то есть на перспективу. Это добавляет привлекательности этому бизнесу, потому что как только руководитель поймёт, что смог достаточно захватить рынок web-дизайна, он сможет расширить спектр своей деятельности. Однако сейчас стоит сказать о самом главном – персонале. В первую очередь это, конечно, дизайнеры, причём именно те, кто обучался непосредственно web-дизайну, то есть в своём высшем учебном заведении освоил специальность, предполагающую знания в области компьютерных технологий. И при этом знающие о том, как именно должен выглядеть привлекательный сайт и как его сделать таковым. Хотя и близкая, но всё-таки отдельная должность – программист, причём их тоже можно разделить на несколько категорий; сведущим в этом людям уточнять не нужно, а вот для дилетантов нужно отметить – есть те, кто пишет код, есть те, кто занимается контентом, есть те, кто добавляет сторонние разработки на свой сайт. То есть один программист явно не справится, особенно если компания хочет заниматься ещё и полноценно разработкой сайтов. Дизайнер и программист – условно две главные штатные единицы. Если, конечно, очень повезёт, то можно найти программиста-художника, который станет заниматься всем и сразу, но… много ли будет успевать один человек?

Готовые идеи для вашего бизнеса

Далее потребуются люди, которые заняты в маркетинге, а проще говоря – в продвижении своих услуг и поиске клиентов. Иногда требуется целая группа людей, которая будет клиентов искать, проводить с ними встречи, заниматься презентациями. Иными словами, это менеджеры по продажам. Но немалую часть почти наверняка будут занимать фрилансеры – это люди, которые выполняют работу только по мере её поступления, работают удалённо и получают заработную плату только по факту проделанной работы. Фрилансеры могут потребоваться для создания каких-то отдельных элементов дизайна, для разработки каких-то частей кода, для копирайтинга/рерайтинга. Найти их обычно несложно, им передаётся относительно несложная задача, зато сотрудничество с ними позволяет существенным образом сократить свои издержки на содержание персонала, потому что во время отсутствия проектов не приходится платить зарплату.

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

Услуги дизайнера предполагают в большинстве случаев создание уникального проекта, который выгодно отличается от конкурентов заказчика. Однако нужно сказать, что немалый процент потребителей приходит в студию web-дизайна с готовым заданием, где чётко прописаны все требования, при этом нередко также передаётся контент, который требуется на портале разместить. То есть дизайнера ставят в рамки, иногда достаточно серьёзные. Но есть и клиенты, которые сами не знают, чего они хотят. Им можно предлагать уже готовые решения, которые были разработаны дизайнерами самостоятельно и представляют собой «универсальный продукт», отличающийся простотой в хорошем понимании этого слова. Но если у клиента нет своего задания, и он хочет получить нечто уникальное, то дизайнер должен быть в состоянии в переговорах с заказчиком точно выяснить то, что ему нужно и вместе с ним разработать задание. Таким образом, хорошая студия изначально имеет пакет своих предложений, готова работать по чёткому указанию и открыта к индивидуальной работе с клиентом. Именно тогда можно говорить об успехе своего бизнеса. Что касается самой технологии создания сайта, то клиенту это обычно не важно, его запрос состоит в том, чтобы было «красиво», «не тормозило», «удобно», «функционально» etc. Заказчика интересует только конечный результат, а не процесс создания или оптимизации/доработки его сайта.

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

Готовые идеи для вашего бизнеса

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

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

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

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

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

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

Веб-студия «Магвай» работает с 2009 года. За это время мы пробовали много разных систем для ведения проектов и только недавно нашли для себя идеальную программную связку. Но, вернемся к началу.

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

Этого «разнообразия» нам хватило на пару лет, а затем в 2011 году мы нашли TaskManager, заточенный под бизнес веб-студии и это был «Мегаплан». В тот момент нашей радости не было предела – клевый интерфейс, с продуманным юзабилити, и весьма удобная начинка. Но скоро наш энтузиазм быстро прошел. Система на тот момент была еще довольно «сырой», функциональность хромала. Было неудобно заносить потенциальные сделки, хранить файлы, ставить задачи. Раздражали слишком отвлекающие элементы, ненужные кнопки, фишки; например, при постановке задачи кнопки окружали форму создания аж с 4-х сторон. Бизнес-процессы было сложно настроить, возможно, для некоторых и вовсе не было подобного функционала. Сейчас, судя по отзывам, «Мегаплан» уже продуманная, функциональная и удобная штука. В 2011-2013 годах это было не совсем так, но за неимением лучшего, мы продолжали работать с «Мегапланом».

В то время также рассматривали и зарубежные аналоги – Basecampи Jira, но англоязычный интерфейс отталкивал, а на освоение многих функций требовалось больше времени, чем мы могли и хотели выделять.

А затем в 2013 году мы открыли для себя Битрикс 24, на котором работаем и по сей день. Это неидеальный продукт, но для начала он был функциональнее и удобнее «Мегаплана». Мы перешли на него почти безболезненно, с переносом и сохранением данных. Данные переносили не сразу, а только когда 1С-Битрикс купили долю в Мегаплане – появилась удобная интеграция данных из Мегаплан в Б24, чем мы успешно и воспользовались.

На сегодняшний момент мы пользуемся Б24, как системой управления проектами, уже 5 лет. Но при этом, это не единственная система, которая помогает нам в работе.

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

На сегодняшний момент связка Битрикс24 + Trello + AmоCRM для нас удобна и закрывает все процессы, начиная с продаж, продолжая планированием задач, и заканчивая самой разработкой.

Битрикс24 имеет достаточно обширный функционал, но есть некоторые нюансы, которые являются для нас не совсем удобными, и есть функционал, которого нам порой не хватает в работе.
Например, очень не хватает приоритетов, которые можно присваивать задачам, выстраивая очередность. Да и сама очередность задач в Битрикс24 не так удобна для нас: каждый раз нужно задавать сортировку. Общая картина – кто и что делает, сколько задач в дизайне, сколько задач у технической поддержки – прослеживается в Битрикс24 с трудом. Последнее – особенно важно, ведь необходимо, чтобы руководители всех звеньев видели занятость специалистов на данный момент, очередь из будущих задач, приоритеты. Только так можно понимать загруженность студии, возможность взять новый проект или выделить время на разработку собственного продукта студии.

Со стороны Исполнителей также есть определенные трудности. Исполнитель видит 100500 различных задач, и, хоть они и объединены по группам, «портянка» от этого меньше не становится. С другой стороны, функционал постановки задач, контроль их выполнения, общение в чате Б24 нас полностью устраивают. Как с этим быть? - Мы нашли решение в виде Trello.

Trello, по сути, обычная канбан-доска, которых существует великое множество, в том же Б24 есть некая встроенная функция доски задач, есть неплохое платное решение от Сибирикс. Но Trello, по нашему мнению, имеет ряд преимуществ:

1. Не нужно платить деньги. Точнее, вы можете приобрести подписку на расширенный функционал, но и того, что предлагают бесплатно, вполне хватает;

2. Простота и интуитивность интерфейса.

3. Кастомизация под нужды команды. Мы создаем только те доски, которые нужны, настраиваем свои списки задач в каждой доске, управляем уровнями доступа к каждой доске, сами настраиваем и присваиваем маркеры к каждой карточке.

Таким образом, все задачи обязательно ставятся в Б24 и дублируются в Trelloв виде карточек с кратким описанием и ссылкой на задачу. Мы видим, сколько задач и на каком исполнителе сейчас, какая очередность у задач и какие статусы (например «сделать срочно» или «баг после тестирования»).

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

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

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

Еще важный момент, которого нам недостает в Б24 – это база потенциальных сделок, контроль работ по ним для отдела продаж. И снова, этот функционал есть в Б24, но нас он категорически не устраивает. Есть ощущение, что его делали технари, без поправки на нужды маркетологов и продажников – настолько, на наш взгляд, там неудобный интерфейс. Поэтому мы не используем встроенный в Б24 механизм CRM, заменяя его еще одним сторонним сервисом AmoCRM.

Если говорить об AmoCRM, то открытие этого сервиса быстро и четко расставило все точки над «И» в секторе продаж студии.

В Amo мы работаем с 2016 года и это настолько приятно и удобно, что прямо проецируется на довольных лицах специалистов отдела продаж.

Система выстроена настолько просто, что освоение ее функций происходит интуитивно. AmoCRM позволяет вести учет всех потенциальных клиентов, просматривать их на общей «доске», прикреплять различные стикеры-этапы (которые, кстати, можно создавать самому) и ставить задачи внутри сделки.

Отдельно можно рассказать о том, что Amo – это удобный справочник всех контактов, которые взаимодействовали с нашей студией во время продажи проектов. Это позволяет хранить всю информацию о Заказчике в одном месте, а не создавать для этого горы архивов. К тому же с данной системой легко осуществлять вторичные сделки, когда клиент возвращается в студию, или когда мы снова «напоминаем» о себе по прошествии времени.

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

Мы, исследовав многие сервисы за долгое время работы студии, нашли и используем максимально удобную для нас программную связку Битрикс24 + Trello + AmоCRM.

Но нет предела совершенству, мы с интересом смотрим на рынок TASKManager/CRM и с удовольствием тестируем что-то новое. Например, для почасовой технической поддержки и для постоянной работы с зарубежными заказчиками уже применяем Slack. Потому что мы всегда стараемся гибко адаптироваться к новым обстоятельствам на рынке веб-разработки или к изменениям внутри студии.

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