Разработка сайта. Стек: HTML, CSS, JS, TS. WebStorm, Angular, Figma, GitHub.
Перейти на сайт

Разработка MVP версии сервиса.
Стек: Drupal проект, развертывание стандартное для Drupal8+ с использованием composer, html, React JS/TS.

Перейти на сайт
Структура сервиса:

1. ЛК пользователя для хранения ПД: PDbook
2. Шаблоны WEB-страниц для передачи ПД: : https://demo.pdbook.ru/
3. API для интеграции ЛК пользователя и WEB-страниц.

Функции сервиса:

1. Удобная передача любого списка ПД физлиц в 1-2 клика
2. Безопасная передача ПД физлиц
3. Безопасное хранение ПД физлиц
4. Обеспечение соответствия ФЗ РФ №152

Ключевое назначение сервиса – это не хранение ПД, а именно заполнение всех форм, содержащих ПД. Сервис для физлиц по хранению и управляемой оперативной передаче персональных данных и реквизитов третьим лицам с соблюдением ФЗ. У Сервиса 2 основных функции, безопасное хранение и управляемая передача данных (фактические, юридические, рекламные и т.д.).

Преимущества сервиса:

1. Безопасность. ПД люди хранят и передают небезопасно (фото, мессенджеры, …).
2. Доступность. В нужный момент не всегда документы с ПД есть с собой.
3. Исключение повторяемости заполнения форм с ПД бесконечно многократна.

Разработка и наполнение сайта "под ключ" для INSOCKS на Tilda: https://in-socks.ru. По ряду ключевых запросов по SEO сайт выведен на 1ю страницу выдачи Яндекса.
Перейти на сайт

До проекта:
Компания оказывала услуги по настройке панелей мониторинга (дашборды) для клиентов. Четко идентифицированный продукт отсутствовал. Стоимость услуг выбиралась по договорному принципу. Успешные продажи выполнял только собственник, продажи отдела продаж равнялись нулю.
Заключенные сделки не выполнялись в срок, опоздание длилось месяцами.
Документация к сделке отсутствовала. Какие дашборды, показатели должны быть настроены в каждой сделке определить было невозможно. Вновь принятый в компанию человек
Ни собственник, ни менеджер отдела продаж, ни клиент не понимали, что именно продает компания, за какую цену и сроки.
Такая деятельность привела к серьезным убыткам и кризису в компании. Компания находилась на пороге закрытия.

По итогам проекта:
В качестве продукта выделен дашборд. В продуктовую линейку включено 2 вида продукта: готовый дашборд из каталога и разработанный на основании ТЗ на заказ.
Сформирован каталог готовых дашбордов.
Разработана ценовая политики: фиксированная стоимость за готовый дашборд и разработанный на заказ.
Создана библиотека показателей по всем процессам деятельности торгово-производственных компаний для ускорения разработки дашбордов.
Спроектирован и внедрен процесс продаж, включая скрипты для менеджеров отдела продаж и документацию процесса продаж (КП, презентация, ТЗ, корректировка договора, регламент процесса).
Оптимизирован процесс исполнения сделки, то есть настройки и разработки дашбордов и сдачи заказа клиенту в указанные в договоре сроки. Теперь аналитик по настройке и разработке дашбордов выполнял работы на основании четкого ТЗ.
Процессы продаж и выполнения сделки были пронормированы. Что позволяет рассчитывать численность отделов-участников, а также прибыль компании.

Результаты и достижения проекта:
Первые сделки были заключены через неделю после внедрения выполненных мероприятий. Время заключения сделки сократилось с нескольких дней и недель до 20-30 мин.
Все 100% заказы стали выполняться в срок. Средний срок выполнения заказов сократился с нескольких месяцев до 1-2 недель.
Процесс продаж стал независим от собственника и успешно работал в отделе продаж. В течение первого месяца работы работая оп новой технологии продаж и выполнения сделок компания вышла +, сгенерировав выручку, достаточную для погашения задолженностей и сохранила позиции на рынке.

Open Alliance - компания осуществляет разработку и поставку телекоммуникационных товаров из Китая, производимых на заказ.
Оборот компании - более 1 млрд. руб.
Сайт компании: http://www.openalliance.ru
​
Ключевые задачи проекта – разработка мероприятий по снижению риска поставки некачественного оборудования.

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

Решение:
Для решения поставленной задачи было сформировано предложение о разработке приложения с применением QR-кода для контроля качества товаров и сроков готовности партии до ее отгрузки на территории производителя в Китае.

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

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

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

Решение:
Разработан файл, который позволяет вести планирование, учет и анализ по процессам: маркетинг, продажи – CRM (база клиентов, планирование продаж, учет заказов), закупки – SRM (база поставщиков, планирование и учет закупок, запасов), финансы (бюджетирование, расчет окупаемости инвестиций, расчет себестоимости, цены и точки безубыточности), учет движения персонала (расчет фонда оплаты труда, формирование системы мотивации), производство (планирование и учет выработки продукции, график работ).

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

Основным видом деятельности фабрики ГРАНД является производство чулочно-носочных изделий (ЧНИ) под собственным брендом и торговыми марками клиентов.
Оптовая реализация ЧНИ осуществляется с помощью крупных ритейлеров, федеральных и региональных сетей: Zara (экспорт), Спортмастер, Декатлон, Магнит, Перекресток, Пятерочка, Глобус, Самбери, Мамси, Остин, Mothercare, Sela, Азбука Вкуса и т.д.; розничная – через маркетплейсы: OZON, Wildberries, собственный интернет-магазин и собственную торговую сеть из 5 магазинов.


До проекта:
Хаотичное накопление ассортимента с момента основания фабрики (более 5000 SKU).
Хаотичное выполнение разработки новых моделей.
Каждая модель могла быть выпущена в виде набора из разных цветов в различном количестве от 2 до 10, принцип выбора которых был не очевиден.
Задания на разработку новых моделей поступали от разных внутренних заказчиков, практически от всех подразделений компании (продажи, производство, закупки, руководство). Задания формулировались всегда в устной форме. Из-за чего переделки в среднем составляли 10 итераций на 1 модель.
Учет разработанных моделей отсутствовал. Общее число разрабатываемых моделей в месяц никто не знал даже примерно.
Техническая документация к новым моделям часто не составлялась.
Ценовая политика и методика расчета цены была единой для всех изделий.


В ходе проекта:
Сформирована ассортиментная матрица, выведен неактуальный ассортимент.
Внедрены принципы и процесс формирования коллекций (например, число изделий в коллекции, что напрямую влияло на развес на крючке у клиента). Регламентированы функции и участники процесса разработки изделий.
Коллекции гармонично дополняют друг друга. Теперь на базе них можно формировать витринные стенды различного формата по требованиям клиента.
Выделены ценовые сегменты в матрице: премиальный, средний и эконом.
Разработаны и выпущены новые коллекции продукции на 2018 г. по категориям и ценовым сегментам (мужская, женская, детская для летнего и зимнего сезонов; премиальная, средний, эконом).

Разработаны и внедрены новые категории продукции (подследники, носки для малышей, детские легинсы, «бабушкины носки», носки и подследники с силиконом).
Разработан новый удобный каталог продукции.
Стандартизирована и внедрена этикетка на все категории продукции по ценовым сегментам.
Разработана и внедрена премиальная упаковка для подарочных наборов носков.
На каждое изделие разрабатывается комплект тех. Документации (спецификации, вязальная карта).
Процессы продаж и разработки автоматизированы с помощью решений Creatio Terrasoft и 1С: УПП.
Организован учет новых моделей в отделе разработок.
Выполнен анализ и нормирование работ отдела разработок.
Создан архив новых моделей.

Результаты:
Известен ежемесячный объем разрабатываемых изделий
Новые модели изделий в 90% случаев сдаются с 1го раза. Переделки устранены. Также устранены переработки в отделе разработок.
Задания на разработку поступают в виде ТЗ только из отдела продаж.

О компании - InSocks, интернет-магазин по печати дизайна на носках. StartUp.
Сайт компании: https://in-socks.ru

Ключевая задача проекта – запуск интернет-проекта с нуля от идеи до воплощения (MVP).
Разработка стратегии и вывод на рынок нового продукта - носков с напечатанным рисунком для розницы и мелкого опта.


Решение:
Анализ рынка ЧНИ показал, что на рынке отсутствует предложение для мелкого опта – небольших тиражей, а также предложение для ряда дизайнов (например, мелких или имеющих более 6-10 цветов). Некоторые дизайны при вязке сильно искажаются, поэтому не устраивают клиента.

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

ТК Боксберри - служба доставки для интернет-магазинов и других компаний дистанционной торговли, работает с 2010 г.
Сайт компании: https://boxberry.ru/

Задача кейса – повышение эффективности работы сервиса - личный кабинет.


Результаты анализа и решения:
1.      После входа в ЛК система очень долго загружается, также как и при создании отправления вручную и после выполнения каждого действия, заполнения каждого поля. Особенно заметны потери времени при создании массовых отправлений. Неудобно и трудозатратно.
2.      При выборе способа доставки меняется число заполняемых полей адреса доставки: при выборе ПВЗ – необходимо в отдельном поле выбрать город, в следующем – улицу и номер дома; при курьерской доставке – адрес вносится в одно поле.
В случае с 2мя полями неудобно, так как адрес обычно переносится копированием, поэтому его удобнее вносить в одну строку вставкой.
3.      При загрузке отправлений через XLS файл возникло сообщение об ошибке. В которой было сказано, далее цитата: «Вес коробки должен быть указан числом у места №1».
Однако указанное поле содержит числовое значение. Очевидно, что это ошибка не пользователя, а системы.
В итоге файл загрузить не удалось.
4.      Также в шаблоне XLS файла, скаченного из ЛК, требуется заполнить поля «Баркод» и «Номер акта передачи». Однако эти данные присваиваются в ЛК Боксберри системой автоматически после загрузки в нее отправлений. То есть пользователю на этапе загрузки они неизвестны. Все формы необходимо протестировать и исправить ошибки.
5.      В поле «ФИО» обязательным является указание Фамилии получателя, что далеко не всегда известно. Поэтому приходится придумывать вымышленную фамилию, например, Юлия Москва. Иначе заявка не будет создана. Бессмысленное и необоснованное требование, которое необходимо исключить.
6.      Отбор записей в реестре отправлений можно выполнять с помощью статусов. Однако число статусов = 67!!! При чем есть дубли статуса «Не в акте». Зачем пользователю видеть весь список статусов, даже те, которые не используются при доставке его заказов?? Сортировка по таким статусам все равно равна 0, но избыточность статусов не позволяет быстро найти нужный. Например, отправления магазина никогда не проходят таможню, так как доставляются по РФ. Наличие полного списка приводит к тому, что работать со статусами и реестром становится неудобно. Необходимо сократить список статусов до уровня присутствующих в реестре записей.
7.  Раздел «Финансы» работает некорректно. Сумма итоговой задолженности не соответствует детализации данной суммы по актам в реестре. Вести контроль расчетов с Боксберри вообще неудобно. Так как отчеты по отправлениям поступают еженедельно по почте в виде нескольких excel файлов, в разделе «Финансы» ЛК информация отличается от той, что имеется в файлах. Необходимо отдельно выделять время на то, чтобы разобраться. Автоматизировать процедуру расчетов довольно просто. Ведь все отправления видны в ЛК. Необходимо добавить в реестр столбец: Тариф, руб. Затем вывести итоги по каждому столбцу (по тарифу и сумме к наложенного платежа) второй строкой под шапкой, где будет отражена сумма по числовым столбцам. Разницу между этими столбцами со знаком +/- вывести в правом верхнем углу над последним столбцом реестра.
Таким образом, пользователь всегда будет видеть сумму задолженности (и порядок ее формирования! чего нет сейчас) или к получению и управлять ею (например, при наличии задолженности отправить заказ с оплатой не только за доставку, но и за заказ, чтобы погасить ее).
Итоги должны формироваться автоматически на текущую дату, при выборе интервала - за выбранный период, включая конечные даты.
8. Печать этикетки. Почему-то при выводе на печать нескольких этикеток печать каждой из них выполняется на отдельном листе А4. Что не экономично. При выборе в настройках принтера печать 2, 4 на 1 листе, масштаб этикетки сильно уменьшается, то есть ее неудобно читать. Необходимо настроить печать этикетки для вывода на стандартные форматы бумаги для массовой печати этикетов.
9. Акты. Если Акты сформированы для списка отправлений, то внести изменения в Акт уже нельзя. Что неудобно. Часто возникают случаи, когда требуется добавить в Акт еще отправления до их передачи курьеру или в ПВЗ. Вместо этого на новые отправления приходится формировать, печатать и подписывать отдельный Акт. Что опять же требует затрат дополнительного времени.

СДЭК - логистический сервис, доставляющий онлайн-заказы через пункты выдачи.
Сайт компании: https://www.cdek.ru/

Задача кейса – повышение эффективности работы сервиса - личный кабинет.

Результаты анализа и решения:
Основными недостатками ЛК является:
1.     Неудобный реестр. Нет возможности проверить данные об отправлении без открытия каждой заявки в отдельности:
1.     В графе «Статус» отражать детальный статус, чтобы избежать дополнительного поиска по трек-номеру места нахождения заказа при обращении получателя.
2.     В графе «Куда» должен быть указан полный адрес: улица, дом, кв.
3.     Добавить графу «Получатель» с номером телефона и ФИО.
4.     Добавить графу «К оплате» с указанием стоимости наложенного платежа.
5.     Добавить графу «Тариф» с указанием стоимости услуг по доставке заказа.
6.     Добавить итоги второй строкой, под шапкой таблицы, для граф «К оплате» и «Тариф» для расчета сумм по каждой графе за выбранный период.
7.     Добавить значение итогов как разницу между графами «Тариф» и «К оплате» рядом со счетчиком записей в реестре.
2.     Раздел «Отслеживание заказа» удалить как дублирующий после реализации п.1.1.
3.     При расчете стоимости услуг за доставку включать в стоимость все услуги и показывать конечную максимальную сумму при заданных параметрах.
Сейчас не включаются звонок получателю курьером и комиссия за прием наличного платежа. Так как доставку в большинстве случае оплачивает получатель при оформлении заказа, данные затраты падают на бюджет магазина как доп.затраты.

РickРoint - логистический сервис, доставляющий онлайн-заказы через постаматы и пункты выдачи.
Сайт компании: https://pickpoint.ru/

Задача кейса – повышение эффективности работы сервиса - личный кабинет.

Результаты анализа и решения: 
1.      Инструкция к личному кабинету общая на уровне описания разделов, детального описания полей нет, а их наименования нестандартны.
2.      Регистрация отправлений возможна при создании отдельной заявки либо массово через загрузку файла Excel. Загрузить отправления списком не удалось, кнопка загрузки файла не работает.
3.      При регистрации отдельного отправления открывается страница, где видим поле «Моб.телефон» получателя, которое состоит из 3-х полей. То есть внести номер телефона можно только ручным заполнением, копированием не получится.
Далее видим поля: «Вид отправления: Оплата по факту, Предоплата» с полями для ввода данных. Предполагаем, что, если заказ и доставка предоплачены клиентом, поля остаются пустыми. Если клиент не оплатил доставку, то вносим в поле «Оплата по факту» сумму платежа, например 300.
Следующий параметр «Сервисный сбор и предоплата». Что здесь имеется ввиду неясно. Предполагаем, что это сумма за услуги ПикПоинт, но о какой предоплате речь? Указываем сумму согласно тарифу. Для этого вручную в отдельном Excel файле нужно найти тариф для города доставки. Автоматически тариф за доставку после ввода адреса не определяется, что очень неудобно. Указали те же 300 руб.
Далее непонятно зачем система в обязательном порядке требует детализацию заказа с указанием стоимости товара. Хорошо, заполнили, указали 500 руб.
Нажимаем кнопку «Сохранить». Появилась ошибка: «Внимание! Указанные суммы по товарам и сервисный сбор не совпадают с суммой к оплате.
Проверьте правильность введённых данных.»
В инструкции значения указанных полей не описаны. Логика оказалась неверной.
Обратились к менеджеру. Менеджер долго не могла разобраться в своем ЛК, но потом все-таки разъяснила.
Оказалось, в графе «Сервисный сбор и предоплата» в поле предоплата необходимо поставить сумму, которая равна сумме заказа, если заказ уже оплачен клиентом.
4.      Отсутствует возможность удалить заявку на заказ и вызов курьера.
ЛК работает медленно, «зависает» на несколько минут. Были случаи, когда после очередного «зависания» системы ошибочно были созданы заявки на вызов курьера. Чтобы избежать приезда курьера был сразу же совершен звонок в ПикПоинт с предупреждением менеджера, что в ЛК содержаться лишние заявки и просьбой их отмены. Менеджер принял сведения и озвучил, что аннулировал заявки. Однако курьер все равно приехал по ошибочной заявке. Позднее был выставлен счет заказчику (!) за ложный вызов! Таким образом, перебои в работе в ЛК должен оплачивать заказчик услуги, по мнению ПикПоинт.