Захожу на сайт https://www.gosuslugi.ru/ (с компьютера, Ваш Полный Нигер отключен) 2. Нажимаю кнопку "Войти" 3. Вхожу по номеру телефона и паролю (записан в спецпрограмме хранения паролей). 4. На следующем этапе после успешного входа по паролю светится клоунада этого жмыха:
Конечно же я нажимаю Пропустить. Пока ещё пускает на Госуслуги
У меня верифицированная УЗ (посещал МФЦ) и при этом мой ОпСоС не подал информацию о моём договоре в Минцифры (Госуслуги считает, что мой номер мне не принадлежит). В настройках "Безопасность"-> "Вход в систему" выбран вариант "Вход с подтверждением".
В апреле 2023 года мы запустили необычный для нас проект - ремонтный сервис нового формата. Первого клиента нашли только в начале лета, но уже с первого проекта удалось достичь запланированной прибыли. Расскажу, как мы создали современную компанию для поколения "новых денег", которые не готовы к тому, что прораб будет класть половину стоимости ремонта себе в карман, а сроки растягиваются без ограничений и почему это оказалось прибыльным бизнесом.
Как всё начиналось
Конец 2022 года. Я работал менеджером проектов в крупной IT-компании, мой друг Антон - тимлидом в другой известной технологической компании, а Дима занимал позицию backend-разработчика в третьей. У всех стабильные зарплаты, интересные проекты - жизнь шла своим чередом, пока Антон не решил купить квартиру в новостройке.
После долгих поисков он остановился на 85-метровой квартире в ЖК около метро Саларьево - современный комплекс с подземным паркингом и зелёным двором. Как типичный программист, к поиску ремонтников он подошёл педантично: изучил десятки предложений, провёл собеседования с кандидатами. В итоге выбрал бригаду с Авито с "15-летним опытом работы".
Денис (это я:) - один из создателей сервиса
За время ремонта у Антона мы с Димой часто приезжали к нему - помочь, посоветовать, и просто поржать над очередными косяками строителей. У нас обоих за плечами был серьёзный опыт управления командами, внедрения процессов, автоматизации и контроля качества. И знаете что? Нам казалось, что главное в ремонтном бизнесе - это грамотный менеджмент и организация процессов. И на самом деле, все примерно так и есть.
День когда мы решились
Если честно, мысли о собственной ремонтной компании появились у нас задолго до этого случая. В IT-тусовке часто шутят, что в России есть три верных пути: вебкам, айти и стройка. И мы, насмотревшись на хаос в ремонтной сфере, не раз обсуждали возможность открытия своей “фирмы”.
Мы выделили основные проблемы, которые должны были исправить с помощью своего сервиса
Первое - это постоянно растущие сметы и "задранная стоимость" на работы. Ну вы серьезно? Почему для меня ремонт в квартире должен чем-то отличаться от заказа носков на Вайлдберриз? Почему-то там нет такого, что цена носков может вырасти в 2 раза за время доставки. А тут начальная смета в 1 миллион превратилась почти в 1,7! И каждый раз это "ой, тут стены кривые", "ой, а тут придется докупить", "ой, а это мы не учли".
Второе - это бесконечно растущие сроки. Это еще хуже. Как люди с опытом в менеджменте, мы прекрасно знали, что растущие сроки – это всегда раздолбайство управления и ленивые рабочие. Но тут было чуть посложнее, об этом чуть позже. У Антона обещали сделать за 4 месяца, а в итоге растянули на 8.
Третье - хитрые прорабы. Это вообще отдельная история. Когда прораб говорит "давайте я сам закуплю материалы, у меня скидки", знайте - он накинет сверху процентов 30-40. А еще есть "срочные работы", которые почему-то не были учтены в смете. И конечно, вечная классика - экономия на материалах: заказываешь одно, а привозят что-то попроще, но по той же цене.
Целевая аудитория
А параллельно с этим мы определили нашу целевую аудиторию. Чтобы выделиться на конкурентном рынке, мы решили ориентироваться на молодых IT-специалистов и представителей “современных” профессий, живущих в Москве в возрасте 30-40 лет. Тех, кто покупает квартиру в новостройке и привыкших к хорошему сервису. Кто не готов, что его будут водить за нос и разводить на деньги.
Что с ценой?
При этом очень важно было держать цены НИЖЕ, чем у других компаний, иначе на рынке просто не выжить. В премиум сегмент нужен "пропуск" в виде большого количества работ для определенного типа клиентов, поэтому нам было понятно, что "брать" много - пока что, непозволительно. Но мы нашли способ: автоматизация процессов, прямые поставки материалов, четкое планирование работ и никаких скрытых накруток. Но несбыточной мечтой это покажется только обывателю: на самом деле сервис и правда должен быть таким, вообще любой.
История первого заказа летом 2023 года
А теперь самое интересное - наш первый заказ. Это была отдельная эпопея. Начало лета 2023, звонок от потенциального клиента.
Первый клиент оказался прямо "в яблочко" - тоже айтишник (пришедший из первой контекстной рекламы в яндексе запущенной на 20 тыс.), работал в крупной компании, купил двушку в панельке 80-х годов. Причем достаточно убитую - стены местами с дырками, старый паркет, трубы помнящие еще Горбачева... Но нам, если честно, даже повезло что первый объект был не новостройкой. На старом фонде учиться легче - там хотя бы есть на что посмотреть, в отличие от новостроек, где все "сюрпризы" спрятаны в голых стенах.
Дырка в стене была ДО демонтажа. Клиент купил квартиру с "убитым" ремонтом подешевле, в надежде сэкономить
Как мы мастеров искали
Начали с поиска бригады. Вот тут был первый холодный душ - оказалось, что найти классных специалистов без своей наработанной базы очень сложно. Мастера хорошего уровня либо уже при деле, либо просят космос. А те, кто сразу соглашается - ну, вы понимаете. За две недели провели больше 10 собеседований (назовем их так😊). Причем процесс собеседования мы сразу сделали "как в айти" - тестовые задания, проверка портфолио, разбор технологий работы. Бригадиры были в шоке - некоторые прямо уходили с собеседований, когда мы начинали распрашивать про технологии укладки плитки и показывали фотографии косяков с объектов с форумов.
В итоге нашли бригаду - два брата, которые до этого работали в крупной ремонтной компании, но ушли потому что устали от "серых" схем – по отношению К НИМ ЖЕ. В основном - задержки з/п и прорабы.
В том же санузле, но уже после демонтажных и некоторых черновых работ. Братья очень помогли нам с первым ремонтом, кроме этого, они дали нам контакты проверенных рабочих, которые впоследствии делали ремонт вместе с ними
Купили первый комплект инструмента - это отдельная история на 100 тысяч рублей. Ещё сразу купили свою тепловую пушку - это из необычного. Большинство компаний привлекают "потолочников" на субподряд. Мы захотели сразу начать формировать свой инструментарий для будущих сотрудников. Зато потом эта закупка очень помогла - не зависели от того, что принесет с собой бригада. Позже, когда начали расширяться купили свою штукатурную станцию. Это, на удивление, было самой выгодной покупкой.
Первые сложности
Начали ремонт. И тут поехало... Первый сюрприз - когда начали снимать старую штукатурку, оказалось что стены буквально рассыпались. Плюс под старым линолеумом в коридоре нашли деревянный пол с насыпью под ним.
Тут был первый серьезный разговор с заказчиком. Объяснили ситуацию, показали все фотки, рассказали что сколько будет стоит в соответствии с прайс-листом. Тут очень помогло то, что мы сразу взяли за правило - фотографировать вообще все. Каждый этап, каждый слой, каждую трубу.
С материалами тоже было весело. Первый месяц я лично объездил все крупные строительные магазины в радиусе 30 км. Искал поставщиков, договаривался о скидках. Помню, как чуть не купили партию плитки по "супер-выгодной" цене, а потом выяснилось что это условно "второй сорт" - брак, который продают через "серые" схемы.
Cделали систему закупок: (Первый заказ полностью сделан из материалов, купленных в Петровиче и на маркетплейсах). Бригада присылает список - мы проверяем цены у 3-4 поставщиков и заказываем где дешевле.
Мы сразу внедрили систему ежедневных фото-отчетов и еженедельных созвонов. Плюс сделали чат в телеграме, куда скидывали все чеки, все накладные, все фотки. Такая прозрачность очень помогла - клиент видел, что мы не химичим с ценами и не пытаемся на нем нажиться.
В итоге сделали.
Братья советовали нам недостающих специалистов по ходу ремонта и постепенно, укладываясь в срок мы сдавали клиенту новый и новый этап. Честно, это было не так сложно как казалось в начале, но нужно понимать, что на самом деле, проблем по ходу ремонта и мелких трудностей было ОЧЕНЬ много, просто мы как люди привыкшие, понимали что сейчас это и есть наша работа , за которую нам платит клиент - взять на себя все заботы по ремонту. Но серьезных форс-мажоров не возникало, максимум понервничали, когда внесли предоплату потолочникам, которых нашли по объявлению, после чего они явно начали задерживать сроки, но в итоге, все обошлось. Нам и до этого было ясно, что чем быстрее мы соберем свой , хотя бы, небольшой штат, тем лучше и выгоднее. Но для этого надо быть уверенным в постоянном потоке заказов, что мы на тот момент, не могли себе позволить.
Главное - мы поняли как надо и как не надо. Все закупки только через нас. Все договоренности - только в письменном виде.
По деньгам первый проект получился условно в ноль - не считая наших вложений в инструмент и рекламу. Но мы получили бесценный опыт, наработали связи с поставщиками (если это можно назвать так пафосно) и главное - поняли, что наша модель рабочая, хотя на тот момент не были в этом до конца уверены. Наши сомнения развеяло лето 2023 года.
1/5
Наша первая работа, которую нам помогли закончить "братья", советуя недостающих мастеров на каждый этап работ. Цена работ для заказчика вышла 750 000 рублей. Летом 2023 года, за аналогичный объём работ авитовские бригады просили до миллиона(!)
Сайт и маркетинг или как мы общаемся с клиентами ещё до первого звонка
Кстати, про сайт. Первую версию мы сделали за пару вечеров на Тильде - максимально простую: фотки, цены, контакты. Знаете что? Он у нас до сих пор такой – но с значительно изменённым UI/UX. Я иногда ловлю себя на мысли - вот мы же, можем сделать что-то крутое, с личным кабинетом, онлайн-сметами... Но потом смотрю вордстат, статистику и думаю - а зачем? Клиенты находят нас, звонят, все работает. Иногда лучшее решение - самое простое.
1/2
На главной странице "в лоб" о том кто мы, наши конкурентные преимущества, специализация и примеры работ
1/2
Сразу "ярко" заявляем о действующих скидках. Кроме этого, простым текстом пытаемся общаться с клиентом и убедить его в нашем сервисе, пока что, не общаясь с ним лично - конверсия в лиды увеличилась значительно, но важно, чтобы все предложения были реальны
А вот ворд стат. За последний месяц нас искали 680 раз не считая статистики переходов по прямой ссылке. Доказательство того, что дорогой сайт не нужен. Наш стоит 6 000 рублей в год, а сделан за 20 часов
Примеры лучших работ как маркетинговый инструмент
1/4
Оставляли подобные фото с примерами работ и вотермаркой в отзывах к жилым комплексам. Отличный маркетинговый инструмент - сразу определяем нужную ЦА и бесплатно заявляем о себе. Точно знаем, что минимум один клиент был из отзывов яндекс - поэтому работает
Как мы масштабировались и разбирались в проблемах ремонта
Теперь про то, как мы начали разбираться в проблемах ремонта и потихоньку расти. Знаете, за этот год мы много думали - почему вообще ремонтные компании задерживают сроки и не могут сделать работу по первоначальной цене? И нашли несколько интересных моментов.
Первое - сроки. Тут даже копать глубоко не пришлось - сам рынок сформирован так, что клиенты просто привыкли к задержкам. "А, ну это ремонт, тут всегда так" - классическая фраза. Благо тут нам помог опыт организации процессов из айти. Четкие спринты, ежедневные отчеты, календарный план. Работает как часы, если не филонить.
Второе - вечно растущая цена. Вот это было сложнее. В новостройках еще можно точно посчитать, а во вторичке... Но благодаря наработкам этот вопрос стал гораздо яснее. При правильно организации процессов, непредвиденные работы лучше оплатить из своих средств, чем терять клиента. Только так и делается сервис.
Третье - больная тема - воровство на материалах. Тут мы конкретно закрутили гайки. Завели строгий учет, до последнего мешка штукатурки. Прорабам сразу сказали - любая жалоба от клиента на нечестность - это конец сотрудничества. Знаете что самое смешное? Когда начали работать честно, оказалось что маржа все равно хорошая. Просто многие привыкли что надо обязательно накручивать еще и еще.
Неприятные особенности прозрачного сервиса
Большинство компаний, которые начинают работать честно, быстро сдуваются. Потому что сам потребитель привык к плохому сервису. Приходишь к клиенту, говоришь "мы все сделаем четко по смете и в срок", а он смотрит с недоверием - "да ладно, так не бывает". Сейчас в 2024-м ситуация получше, но рынок все еще очень консервативный.
Продвижение или как мы брали “Новую Москву”
Наш любимый Прокшино в Новой Москве - в 2024 году, это самый перспективный район в котором покупатели - наши потенциальные клиенты
Расти начали потихоньку. Сначала сделали специальные цены для новой Москвы - там как раз много новостроек, где мы хорошо научились работать. Потом пошли заказы по рекомендациям. Когда я говорю “пошли” заказы нужно понимать, что это 1-3 заказа в месяц стабильно, что на самом деле, тогда казалось не мало. С рекламой экспериментировали забавно - оставляли визитки в подъездах (да, просто старые добрые визитки!), ставили рекламные ящики у офисов продаж в дни выдачи ключей.
Был случай, когда на одном ЖК поставили такую стойку, а через неделю риелтор оттуда сам позвонил и предложил взять себе процент, если клиент пойдет к нам.
Сейчас берем 2-5 заказов в месяц, (летом было 5 в месяц, если разделить). Большинство клиентов приходят по рекомендациям. Штат за год работы постепенно собрали свой. Трудоустроено 14 сотрудников. Если их не хватало (как летом), привлекали мастеров с которым уже работали раньше, по договору ГПХ. Просили всех регистрировать самозанятость или ИП – это было тяжело, но зато честно платим налоги по Доходы – расходы.
Как устроен процесс
Знаете, что самое сложное в ремонтном бизнесе? Нет, не поиск клиентов и не работа с материалами. Самое сложное - это выстроить систему, которая будет удовлетворять запросы клиента и при этом позволит компании зарабатывать. Мы долго думали над этим и придумали несколько интересных решений.
Начнем с оплаты. Если посмотреть на московский рынок, там забавная система - вроде бы без предоплаты, но это только за первый, самый дешевый этап. А потом - бац, и клиент должен внести 50% от всей суммы. И попробуй не внеси - бригада уйдет на другой объект. Мы сделали иначе: разбили весь ремонт на этапы (их получилось 12 для капитального ремонта), и берем предоплату только за текущий этап. То есть клиент всегда понимает, за что именно платит, и может контролировать процесс.
С договорами тоже интересно получилось. Сначала делали один стандартный, а потом поняли - люди разные, запросы разные. Сейчас у нас три варианта: просто на работы (для тех, кто сам хочет закупать материалы), на работы плюс материалы (самый популярный), и полный пакет с дизайн-проектом. Кстати, про дизайн - мы не держим штатных дизайнеров, работаем с фрилансерами. Так получается и дешевле для клиента, и качество выше - каждый дизайнер специализируется на своем стиле.
Первый образец договора, который ставили на сайт
Расчёт стоимости
Расчет стоимости работ - отдельная история. Когда начинали, было очень сложно. На рынке нет четких цен - один мастер берет 3 тысячи за квадрат стяжки, другой - тысячу, третий вообще говорит "ну давайте посмотрим по факту". Сначала работали по среднему прайсу, но часто уходили в минус по отдельным этапам - то бригада дороже встанет, то материала больше уйдет. Сейчас, когда появились постоянные сотрудники, стало проще - мы точно знаем их расценки и можем давать фиксированную цену.
Материалы
Выяснилось, что в крупных магазинах часто дешевле в сравнении с рынками стройматериалов, особенно если ловить акции. Плюс появились маркетплейсы - там вообще красота по ценам. И главное - полная прозрачность, клиент сам видит все позиции. Если находим материал дешевле - возвращаем разницу. Был случай, когда на керамограните сэкономили клиенту почти 30 тысяч - просто потому что, нашли ту же плитку в другом магазине по акции.
Как работаем сейчас
Сейчас берем 2-5 заказов в месяц, зависит от сезона и сложности объектов.
Процесс обкатан до мелочей: сначала выезд на замер, потом предварительная смета. Если клиента все устраивает - детальный расчет и договор. Дальше начинается самое интересное - согласование материалов, закупки, работа.
Особенности продвижения и подводные камни
С продвижением интересно получилось. Сначала, как все, полезли на Авито. И знаете что? Не зашло. Там своя специфическая аудитория и конкретно у нас, с Авито “ не пошло”.
Свежий пример страницы с авито в категории "Ремонт квартир". Как клиенты определяются с подрядчиком среди тысяч однотипных объявлений - хороший маркетинговый вопрос, который мы решаем, после чего полноценно "зайдём" на авито
Пробовали контекстную рекламу яндекс - тоже так себе результат. Клики дорогие, конверсия низкая. Зато отлично зашла таргетированная реклама в Instagram* (*запрещен в РФ) и реклама в районных пабликах ВКонтакте. Особенно в группах новостроек в ТГ - там как раз наша целевая аудитория.
Но главный канал - сарафанное радио. Причем работает оно интересно. Всегда знаешь , от кого пришли заказчики и проще выстраивать коммуникацию. Есть клиент - он доволен, рассказал коллегам - и понеслось. За три месяца получили еще два заказа от сотрудников той же компании. Выходит такой “корпоративный ремонт”)))
Были, конечно, и провалы в продвижении. Пытались работать с риелторами - предлагали им комиссию за клиентов. Не пошло - у них свои схемы, свои бригады. Пробовали давать рекламу в лифтах, входных группах - тоже мимо, ни одного обращения, но тут скорее из-за того что эта реклама буквально на день.
ИТОГ
Сейчас мы существуем уже чуть больше года и в целом смотрим на ремонтный рынок не так, как раньше. За это время мы сделали несколько важных заметок для себя:
Оказывается, большинство проблем в ремонте - это не технические сложности, а банальная организация процессов. Когда все четко спланировано и каждый знает что делать - даже самый сложный ремонт идет как по маслу.
Мы поняли, почему многие компании "химичат" с ценами и сроками - просто потому что не умеют нормально считать и планировать. Когда все процессы выстроены правильно, можно работать честно и все равно оставаться в плюсе.
Самое сложное - это не найти клиентов или научиться делать ремонт. Самое сложное - это переломить привычку рынка работать "по-серому". И заказчики, и исполнители настолько привыкли к непрозрачным схемам, что честный подход вызывает удивление.
Мы до сих пор учимся. Каждый объект - это новый опыт и новые вызовы (особенно по части коммуникаций с клиентами). Но главное - мы видим, что наша модель работает и пока что, нам удается держать ценник немного ниже рыночного, за счёт того что до сих пор не имеем в найме маркетологов, IT, отдела продаж и менеджеров по продажам. Стараемся нанимать именно рабочих, все остальное можно отдать на аутсорс.
Уважаемые пикабушники, были рады составить для вас эту статью! С любовью, СК Комната
Что ж, я писал пост-певдоанализ (Индустриализация нового века глазами новичка), не совсем подробный но считаю хорошим обзорным. Если это станет пилотным проектом и по чуть придет в экономику то не будет качалей с яйцами и поутихнет инфляция. Но будут иные проблемы: планирования производства и стимулирования роста. Но это уже проблемы совсем не глобальные.
Конспект семинара "Информационная модель организации", который проводил в "Иннополисе" (вдруг кому )
Поднимая тему цифровизации организации или процессов важно не упускать контекст
В первую очередь речь идет об осознанности и согласованности цели, ради достижения которой затеваются перемены
Далее - важно четко осознавать существующий контекст самой организации, состоящий из ключевых объектов и процессов (не только внутри организации, но и во внешней среде)
Каждая организация - уникальна!
Данные - первичны - они отражают факты, из которых соткана жизнь
«Мир состоит из фактов, а не вещей» (объект, предмет). Это означает, что мир состоит не из объектов, а из того, что с этими объектами случается, происходит т.е. из фактов. Соединение разных объектов и есть атомарный факт Людвиг Витгенштейн
Один из ключевых управленческих вопросов - на каком качественном уровне находится инфраструктура по сбору, обработке и передаче данных о всех значимых фактах в организации (в контексте ключевых процессов)
Эволюция информационных технологий (железо, софт, инфраструктура) достигла той стадии, на которой даже небольшая организация может позволить себе создание и эксплуатацию системы, собирающей и работающей с данными в логике тех фактов, которые нужны всем заинтересованным лицам
Озвученная система не обязательно должна быть реализована в виде эксплуатации одного единственного программного продукта (волшебный черный ящик). Все большее распространение набирает микросервисный подход или - Микросервисная архитектура
Прежде чем разрабатывать или покупать какое-либо программное обеспечение - в организации должна наступить относительная ясность и согласованность в вопросе о данных (какие данные нужны? кому? зачем? по каким правилам их обрабатывать?)
Необходимо отрефлексировать ключевые факты и объекты управления в организации и сформулировать понимание, как их отразить в цифре (данные в цифровом формате)
Качество процесса и результата рефлексии во многом зависит от используемого языка участниками процесса
Новые опьяняющие возможности "цифры" повышают требования к процессу и результату начального проектирования целевой информационной системы
При этом, как показывает практика, единого языка и стандартов проектирования информационных систем - не существует
Требования и необходимость создания "Информационной модели здания" (BIM, building information model) - яркий практический пример смещения акцентов в рамках новой парадигмы проектирования в конкретной отрасли - строительство
Эра информационных моделей организаций - уже началась
Один из ключевых вопросов текущей повестки дня - не про наличие или отсутствие информационной модели в конкретной организации, а - про качество компетенций в сфере построения информационной модели (мир постоянно меняется)
Одни из ключевых составляющих общей информационной модели организации являются:
1. Модель процессов
2. Модель данных (объектов управления)
Как показывает практика - феномен "модели процессов" худо-бедно существует в массовом сознании и фигурирует в российской управленческой культуре
Модели BPM-схем - не являются нераспознаваемыми египетскими иероглифами со стороны большинства руководителей и аналитиков
Ключевая атомарная единица в модели процесса - действие или условие
А вот "модель данных" - является полностью диковинной концепцией для российской (и не только) управленческой практики и мысли. Для подтверждения данного тезиса - изучите любое техническое задание на разработку информационной системы (даже со стороны самого продвинутого заказчика) - модели данных вы там не найдете (изредка встречаются модели процессов)
Вместе с тем - "под капотом" любого программного обеспечения "сидит" модель данных (1С, SAP, Битрикс24 и др.)
Модель данных - это система, отражающая ключевые сущности (объекты управления), их атрибуты и связи
Модель данных - логическое отражение конкретной управленческой (жизненной) ситуации (системы), которая рассматривается как совокупность объектов (сущностей) и их связей
Каждый элемент модели данных - это "цифровая полка" (контейнер) для размещения (отражения; учета) ключевых фактов конкретной деятельности конкретной организации
Атомарная единица модели данных - полка для факта
Мало кто знает, но сказку "О рыбаке и рыбке" я создавал на основе модели данных. Коллегам из NL!A удалось найти мои тайные рукописи и восстановить эту модель данных (ссылка в Михайловское) Александр Сергеевич Пушкин
Прежде чем перейти к методологии построения модели данных и процессов важно подсветить риски, которые возникают при игнорировании указанных моделей на этапе проектирования
Как и в любой проектной деятельности - ключевой риск-следствие низкого качества проектной документации - срыв проекта; существенное отклонение реальности от ожиданий (по сроку, бюджету, итоговому результату)
Модель данных и процессов разумно рассматривать как корневой фактор управления ожиданиями всех участников проекта цифровизации
Игнорирование же моделей на этапе проектирования - приводит к росту энтропии
Анти-пример из практики - Техническое задание на разработку информационной системы объемом 280 страниц, в котором словосочетание "база данных" встречается лишь два раза (в тезаурусе); модель данных - отсутствует; модель процессов - описано 4 частных процесса (из десятков)
В итоге получили очередную иллюстрацию тезиса об отсутствии единого языка проектирования информационных систем - 280-страничное техническое задание в режиме потока мысли описывает желаемое поведение будущей системы "Елена" антропоморфным языком ("Елена должна", "Елена будет" и т.п.)
Резюме по данном конкретному ТЗ - все 280 страниц нужно перекладывать с языка "Елена должна" на языки модели данных, процессов, машины состояний, UX и иные
Переходим к языкам "модели данных" и "модели процессов"
Возьмем конкретный пример-факт: моя Дочь собирается сдавать ОГЭ по информатике, а в нашем замечательном НГУ есть Высший колледж информатики, в котором есть актуальный для нее курс:
Кратко - процесс "трудоустройства" на курс происходил следующим образом:
1. Изучение сайта и нахождение программы
2. Звонок - переговоры с менеджером
3. Заполнение договора (обсуждение по email)
4. Оплата
5. Получение паролей и явок для обучающегося
Ничего сложно
Теперь - переложим данную фактическую ситуацию на язык модели данных
Модель данных состоит из категорий-объектов (полок для размещения на них существенных фактов) и связей между ними
Информация - это различие
Проверьте себя: в представленной ниже модели данных (рисунок-схема) не хватает как минимум одного ключевого объекта (категории для фиксации факта), сможете "увидеть" какого?
Очень смахивает на настольную игру - не находите?
Обратите внимание на следующие различия:
1. Описание ситуации антропоморфным языком у меня состояло из 5 пунктов (буллит-поинтов)
2. Описание ситуации языком модели данных состоит из... одной картинки
3. При этом в модели данных выделены 9 ключевых объектов управления (полок для учета фактов) - что более полно отражает ситуацию
4. Картинка с моделью данных - не требует дополнительных письменных разъяснений традиционным языком для извлечения из нее смыслов (данные -- > информация --> знание)
P.S. У вас еще есть шанс найти пропущенный объект / сущность (полку для складирования значимого факта). Ответ - далее
В текущей конфигурации модели данных никоим образом невозможно учесть факты коммуникаций между заказчиком и менеджером - случился телефонный звонок, а также переписка по email'ам (что в конечном итоге привело к продвижению по воронке продаж - к заключению договора и оплате услуг)
Т.е. для учета факта коммуникаций (менеджер-заказчик) в модель данных необходимо добавить дополнительный объект (таблицу базы данных) "контакт с заказчиком" (рабочее название), в котором в последующем будет вестись учет фактов коммуникации (дата, время, участники, результат и пр.)
В итоге - полученная модель данных отражает логику CRM-решений
Кант давно уже говорил, что этот кусок мела содержит миллион потенциальных фактов (Tatsachen) , но лишь очень немногие станут подлинными фактами, воздействуя на поведение сущностей, способных реагировать на факты. Вместо кантовых Tatsachen я бы употребил слово различия и заметил бы, что количество потенциальных различий в этом меле бесконечно, но очень немногие из них станут эффективными различиями (т.е. единицами информации) в умственном процессе некоторой большей сущности. Информация состоит из действенных различий. Грегори Бейтсон, "Разум и природа. Неизбежное единство", 1979г.
Далее нарисованная модель данных (хоть на ватмане) с легкостью перекладывается уже в решение, позволяющие проектировать боевые базы данных (разрабатывать цифровые решения)
Как показывает практика - также нарисованная модель данных является отличной диагностической картой для организации. После того как модель нарисована (спроектирована) диалог об управленческих проблемах в организации протекает на другом уровне качества, с большей эффективностью
В ответ на вопрос "где болит"? Руководители имеют возможность просто "ткнуть пальцем" в рентгеновский снимок организации
Коммуникация происходит на принципиально ином языке
В приведенном примере с трудоустройством на курс очевидное проблемное место - неэффективный обмен данными между заказчиком и менеджером (договор через email, отправка скана чека как доказательство оплаты и т.п.)
Для иллюстрация контраста между логикой и сутью моделей (данные VS процесс) - отразим пример с курсом - языком модели процесса (оригинал модели по ссылке)
Карта (модель) всего процесса выглядит следующим образом:
Детализация начала модели процесса (для понимания логики, без погружения в оригинал) - каждый элемент модели - это действие/событие (тоже факт) или условие ("все устраивает?")
Обратите внимание - язык модели процессов имеет строгую последовательность - в отличии от языка модели данных (важный нюанс!!!)
Модель процесса ВСЕГДА СЛОЖНЕЕ модели данных (см. количество элементов)
По мере наработки наших компетенций по проектированию информационных систем, наступая на грабли и набивая шишки, мы опытным путем пришли к тому, что модель данных - первична! (По отношению к модели процессов, равно как и в контексте создания информационной модели организации)
Качественно спроектированная модель данных организации - максимально близко, целостно и эффективно (минимум знаков) описывает конкретную уникальную управленческую ситуацию в организации
Спроектированная (нарисованная) модель данных становится новым языком (объектом и средством коммуникации) для обсуждения системы управления в организации, понимания сути ее деятельности, актуальных проблем и болей руководства; линейного персонала
Помимо того, что спроектированная (нарисованная) модель данных - уже становится самостоятельной ценностью для конкретной организации, также модель данных становится фундаментальным фактором успеха создания (или улучшения) будущей цифровой информационной системы управления организацией
Записали видео с демонстрацией разработки бизнес-приложения (веб-сервис) для магазина электротехники (хронометраж - 11:45)
Разработка ведется на основе нашей open-source платформы NL!A Framework, использование которой позволяет увеличить скорость разработки в 50 раз
Разработка ведется по принципу единого окна - кодогенератор платформы создает сразу код, как back-end’а, так и font-end’a (тот самый Low-code, о котором так долго говорили Большевики!)
Используемый стек технологий:
1. Интерфейс - Интерфейс создается при помощи Vue.js в современном стиле Material design от Google
2. Веб-сервер создается на языке Go (также от Google)
3. Создается система управления базой данных (СУБД) - PostgreSQL
Рефлексия собственного опыта изменения подходов к бегу
Во время сегодняшней пробежки по лесам Новосибирского Академгородка произошла интересная рефлексия - насколько существенно цифра (гаджеты и данные) изменила мой подход к бегу за последние три года
При чем цифровая трансформация моего подхода к управлению бегом происходила именно постепенно - в течение 3 лет (2018-2021). Постепенно возникали новые сущности, новые данные, трансформировалось мое целеполагание в беге
Ламповый бег
До "цифры" (датчиков и гаджетов) мой подход к бегу выглядел следующим образом: у меня был один единственный маршрут - размеченные лесные тропинки Академгородка на карте в 2gis
Это был маршрут протяженностью около 5 километров. Я знал, что это плюс-минус комфортное расстояние для меня и если силы и будут покидать меня, то покинут меня они не далеко от дома)
Дальше весь управленческий интерес забега сводился к одной единственной метрике - за какое время я пробегу данный фиксированный маршрут
С приобретением фитнес-браслета в 2018 году мой подход к бегу начал претерпевать постепенные изменения
Бег на основе данных
В 2018 году я обзавелся фитнес-браслетом Mi Fit 3, который неожиданно поспособствовал созданию и эксплуатации моей цифровой беговой инфраструктурой
Ядром цифровой инфраструктуры стало мобильное приложение Mi Fit
Теперь во время каждого забега данные о шагах и пульсе отправлялись с браслета в телефон и далее - в приложение
Функционал телефона в забеге:
1. передача данных с GPS-трекера в приложение
2. "Озвучивание" обратной связи от приложения (статистика каждого километра, пульс, темп и прочие данные о полете)
Первая стадия цифровой трансформации бега - бег в режиме свободной охоты
Благодаря тому, что по факту каждого освоенного километра я теперь стал получать голосовой отчет от телефона, а быстрый взгляд на браслет позволял получать данные о километраже с точностью до десяти метров в режиме реального времени - я отвязался от своей "ламповой карты" и стал бегать по рандомным маршрутам, принимая управленческое решение в моменте
Как результат - вышел из зоны комфортного лампового пробега в 5 километров. Целеполагание по освоенному километражу корректировалось уже в процессе забега. так сказать - в режиме реального времени
В результате нового подхода объем пробежки увеличился на 50%+ (средняя температура по больнице)
Ключевой интригой финала каждого забега стало получение отчета - дэшборда в телефоне с кучей метрик - значений различных параметров забега (время, темп, калории, пульс, шаг и многое много другое)
Благодаря изучениям отчетов в телефоне открыл для себя великое знание - оказывается - пульс меняется в процессе бега :)))
Вторая стадия цифровой трансформации бега - бег по пульсу
Открыв для себя такую новую сущность, как пульс - приступил к изучению, что это такое и про что он в процессе бега
Собственно уже отчет в приложении тонко намекал, что в зависимости от значений твоего пульса, бег будет иметь различную направленность (аэробные/анаэробные нагрузки, сжигание жира и др.)
Стал внимательнее изучать собранную статистику по пульсу во время бега. Интересные данные от цифры, без нее - такую статистику собрать невозможно
По теме пульса при беге ключевое управленческое внимание было направлено на то, чтобы не бегать в "красной зоне" пульса - контролируем риск отбросить копыта
В настройках приложения есть возможность настроить алерты о превышении порогового значения пульса. В случае превышения порогового значения (140 ударов в минуту, например) - телефон начнет методично говорить тебе об этом каждые 2 минуты
Тут мы мы подходим к теме качества и достоверности данных
До сих пор помню этот забег по зимнему лесу в 2020 году: начав с оповещения о пульсе в 180 ударов, уже через 5-10 минут последующего забега телефон спокойно и методично рапортовал мне о пульсе в 210+
Забег пришлось остановить. Вот он - конкретный пример принятия управленческих решений на основе данных (data-driven management)
Последующие тестовые забеги также быстро загоняли меня в критическую зону пульса (по версии датчика и приложения), что весьма меня не радовало, мягко говоря
По итогам концентрации своего мыслительного процесса на теме высокого пульса при беге удалось изобрести велосипед - пульс можно замерить "ламповым" способом и сравнить с "цифрой"
Был оперативно проведен эксперимент со следующими результатами:
1. "Цифровой" пульс ~ 200
2. "Ламповый" пульс - 140-150
Вывод: мобильные цифровые датчики не очень точно (мягко говоря) справляются с задачей сбора данных о нашем пульсе (процесс сердцебиения)
Изучив тему пульса обратил внимание на следующую метрику процесса бега - каденс
Третья стадия цифровой трансформации бега - бег по каденсу
Если слово пульс было мне знакомо, то слово каденс - являлось для меня семиотической загадкой, разгадка которой очень сильно повлияла на мою тактику бега
Оказалось, что каденс - это фактическое количество шагов в минуту, которое ты совершаешь. Все просто
Очевидно, что собрать подобные данные, возможно исключительно при помощи цифровых технологий (любителей считать количество спичек в коробках - в расчет не берем)
Благодаря тому, что все ключевые данные о моих забегах хранятся в базы данных приложения - поднял метрики каденса в "докаденсную эпоху"
В общем мой фактический каденс (средний по больнице) при забегах находился на уровне ~120 шагов в минуту
Чтобы понять, насколько я каденс-молодец, а также чтобы быть во всеоружии в ситуации когда мне придется меряться своим каденсом с кем-либо, я направил все свои исследовательские ресурсы на ютуб и выяснил следующее:
Просвещенные люди бегают с каденсом 180
Продифференцировалась интересная диалектика бега:
1. Меньшее количество шагов, но зато шаг - от души - бег прыжками
2. Большее количество мелких шагов - логика швейной машинки
После каденс-просветления для меня стало чуть более понятнее - зачем разработчики приложения зашили в приложение метроном
Первый же забег с метрономом на 180 - показал значимый контраст с предыдущими забегами непросветленного человека (каденс 120)
Гипотеза, что рост частоты топанья ногами на 50% измотает значительно быстрее - не подтвердилась. Наоборот - случился определенный сдвиг в сторону состояния потока, явно снизилась нагрузка на колени, бегать стало лучше - бегать стало веселее!
Практикую бег под метроном уже больше года - качество процесса и результат - явно улучшили по сравнению с "ламповым" и непросвещенным бегом
Обратите внимание, как уменьшился разброс фактических значений каденса с бегом под менторством мудрого метронома - 174-177 шагов в минуту
Что такое метроном с 180 ударами в мнинуту - можете услышать в этом ролике:
Резюме
1. Практикуя ламповый бег, неожиданного - через покупку датчика на руку - погрузился во вселенную различных сущностей, отражающих качество такого бизнес-процесса как бег
2. Дэшборд с отчетом по каждому забегу - теперь неотъемлемая компонента бега
3. Без без цифры - деньги на ветер
4. Все данные о забегах с 2018 года хранятся в базе данных и доступны в любой момент времени (вплоть до статистики по конкретному километру)
5. Телефон стал не только пассивно фиксировать информацию о беге, но и стал субъектом управления бегом - через импульсы метронома
6. Через изучение зоопарка сущностей и эксперименты (забеги-гипотезы) удалось прокачать свои беговые компетенции, равно как и улучшить качество процесса - бега
7. Процесс цифровой трансформации бега занял 3 года
8. Важно - обобщить! Бег - это просто частный процесс! Аналогичная магия и метаморфозы начинают возникать, если плотно взяться за цифровизацию любого процесса в любой организации
9. Как показывает наша практика содействия в цифровизации систем управления компаниями - сознание собственников и руководство компаний также трансформируется по принципу "вкус приходит во время еды". Ключевое - с чего-то начать - задуматься о покупке "браслета", а там дальше ниточка цифровой прокачки и потянется...
В рамках повышения технологической грамотности наших заказчиков - подготовили материал с пошаговым описанием создания модели данных по произведению А.С. Пушкина "Сказка о рыбаке и рыбке" (Золотая рыбка). Вдруг кому :)
Модель данных - ядро информационной системы
Давайте спроектируем модель данных на примере сказки (кейса) "О рыбаке и рыбке" Александра Сергеевича Пушкина
Модель данных - это система, отражающая ключевые сущности (объекты управления), их атрибуты и связи
Модель данных - логическое отражение конкретной управленческой (жизненной) ситуации (системы), которая рассматривается как совокупность объектов (сущностей) и их связей
Давайте разберем - какие ключевые сущности (объекты) мы видим?
Старик и Старуха - это люди. С точки зрения проектирования информационных систем это один объект (сущность) - человек. Однако, для наглядности визуализации и восприятия не погруженного в тему проектирования давайте создадим - два объекта
oldWoman - Старуха
oldMan - Старик
Движемся дальше. Тезис, что "Старуха своя" - толкуем таки, что Старик и Старуха сформировали ячейку общества - Family
Уже возникают интересные нюансы в проектировании и построении учетной информационной системы
Связь oldWoman - oldMan можно реализовать и без таблицы Family добавив Старику и Старухе по атрибуту (строке), содержащему ссылку на супруга spouseId и
указав взаимные связи между объектами
Такой подход с одной стороны - облегчит проектируемую систему (минус одна таблица), но с другой стороны и уменьшатся учетные возможности нашей информационной системы. Если Старик разведется со Старухой (удалится связь; сорри за спойлер), то мы потеряем данные, что они были женаты
Использование же таблицы Family (для учета семей), позволяет нам хранить в базе данных всю актуальную и архивную информацию о таком важно объекте управления, как - семья
Движемся дальше - фиксируем новые сущности (объекты)
See - море (которое "самое синие")
Land - суша, на которой живут Старик со Старухой
По сути - это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы
p.s. По уму See и Land это просто два разных представителя (конкретизация) такой сущности как Пространство (как Старик и Старуха - Человек), однако для простоты восприятия мы их различим
Они жили в ветхой землянке Ровно тридцать лет и три года. Старик ловил неводом рыбу, Старуха пряла свою пряжу
Видим, что живут они не в чистом поле (Land), а в ветхой землянке - Building (называем так, потом что Building будет претерпевать значимые физические и информационные изменения; сорри за спойлер)
Стаж проживания в тридцать лет и три года можно отнести как к свойству Family, так и к связи Family - Building (Тонкое отличие: семье может быть 33 года, но проживали они в разных локациях). Однако не будем перегружать нашу модель в виду несущественности данной информации в нашем кейсе. Равно как и проигнорим пряжу, но не - невод
FishingTool - невод
Обратите внимание на связи:
Family связана (проживают) с Building, а Building в свою очередь находится (связано) на Land.
Ну а инвентарный номер fishingToolId логически закреплен за oldMan
Далее. От статической картинки дошли до процессов - "старик ловил"
Обратите внимание - бизнес-процесс "ловля неводом рыбы" (и его результат) пока никак не могут быть отражены в нашей модели данных. Пока у нас имеется только oldMan, fishingTool и связь между ними
Раз он в море закинул невод, — Пришел невод с одною тиной. Он в другой раз закинул невод, Пришел невод с травой морскою
Заброс невода в море - транзакция
Дошли до более тонкой темы - как организовать учет процесса и его результата
FishingAct - один заброс невода в море
Обратите внимание на параметры (атрибуты) FishingAct:
id - уникальный идентификационный номер (уже случилось два FishingAct)
fisher_id - идентификационный номер рыбака (у нас рыбак один - oldMan, но в теории их может же быть много )
fishingTool_id - идентификационный номер FishingTool (у нас это - невод, но может быть и удочка и запрещенка же всякая с разными инвентарными номерами)
sea_id - идентификационный номер Sea, в котором рыбачим (предусмотрим возможность рыбалки в различных водоемах)
startTime - дата и время заброса FishingTool в Sea
endTime - дата и время извлечения FishingTool в Sea (по разнице endTime - startTime - можно вычислить продолжительность операции)
result - описание того бесполезного, что оказалось в FishingTool по результатам fishingAct (типа, трава морская и прочее)
isGoldFish - оказалась ли в FishingToolgGoldFish? (boolean)
Пока ход бизнес-процесса "ловля рыбы" и его результаты отражаются следующими данными в нашей информационной системе:
В третий раз закинул он невод, — Пришел невод с одною рыбкой, С непростою рыбкой, — золотою. Как взмолится золотая рыбка! Голосом молвит человечьим: «Отпусти ты, старче, меня в море, Дорогой за себя дам откуп: Откуплюсь чем только пожелаешь.» Удивился старик, испугался: Он рыбачил тридцать лет и три года И не слыхивал, чтоб рыба говорила. Отпустил он рыбку золотую И сказал ей ласковое слово: «Бог с тобою, золотая рыбка! Твоего мне откупа не надо; Ступай себе в синее море, Гуляй там себе на просторе».
Очевидно, что у нас возникает объект GoldFish. Но это еще не все!
Также возникает уже "невидимый" объект - обязательства GoldFish перед OldMan. И это будет отдельный объект, при чем он будет спроектирован в логике связей - "многие к многим" (Для сравнения - связь OldMan - FishingTool - "один ко многим" - у одного рыбака может быть несколько девайсов для рыбалки, но у каждого девайса будет ровно один хозяин-рыбак)
GoldFish_OldMan_commitment - таблица по учету обязательств GoldFish (могу быть разные) перед OldMan (тоже могут быть разные; отсюда и логика связи "многие-к-многим"). Таблица для учета "рыбьей дебиторки" OldMan'а
При этом пока эта таблица - пуста («Бог с тобою, золотая рыбка! Твоего мне откупа не надо; Ступай себе в синее море, Гуляй там себе на просторе»)
Обратите внимание, что мы установили связь между GoldFish и Sea (убираем риск, что oldMan может забыть к какому Sea потом идти с каждым новым Commitment; сорри - спойлер)
Также по уму напрашиваются два существенных атрибута для GoldFish_OldMan_Commitment - дата и время возникновения обязательства (дебиторки), и дата и время исполнения обязательства (погашения дебиторки), но мы опустим данные параметры для упрощения модели (к тому же - точные данные этих параметров - безвозвратно утеряны)
Также обращаем внимание, что дальше меняется структура бизнес-процессов. FishingAct более не происходит - вся дальнейшая движуха происходит на связях OldMan с OldWoman и GoldFish
Воротился старик ко старухе, Рассказал ей великое чудо. «Я сегодня поймал было рыбку, Золотую рыбку, не простую; По-нашему говорила рыбка, Домой в море синее просилась, Дорогою ценою откупалась: Откупалась чем только пожелаю. Не посмел я взять с нее выкуп; Так пустил ее в синее море». Старика старуха забранила: «Дурачина ты, простофиля! Не умел ты взять выкупа с рыбки! Хоть бы взял ты с нее корыто, Наше-то совсем раскололось».
Не будем плодить новую информационную сущность про "коммуникационный акт" между OldMan и OldWoman (кстати, до этого и не коммуницировали в нашей кейс) - с управленческой точки зрения для нас важен факт того, что OldWoman формулирует содержание GoldFish_OldMan_Commitment и ставит соответствующую задач OldMan
Теперь у нас в базе данных появляется следующая запись (по аналогии с FishingAct)
Вот пошел он к синему морю; Видит, — море слегка разыгралось. Стал он кликать золотую рыбку, Приплыла к нему рыбка и спросила: «Чего тебе надобно, старче?» Ей с поклоном старик отвечает: «Смилуйся, государыня рыбка, Разбранила меня моя старуха, Не дает старику мне покою: Надобно ей новое корыто; Наше-то совсем раскололось». Отвечает золотая рыбка: «Не печалься, ступай себе с богом, Будет вам новое корыто». Воротился старик ко старухе, У старухи новое корыто.
Еще пуще старуха бранится: «Дурачина ты, простофиля! Выпросил, дурачина, корыто! В корыте много ль корысти? Воротись, дурачина, ты к рыбке; Поклонись ей, выпроси уж избу».
Ускорим сказку и сразу отразим всю историю транзакций в таблице GoldFish_OldMan_commitment (осторожно - много спойлеров!!!)
isKorytoExist - true
isKorytoBroken - true
Теперь вспомним вот эту фразу:
"По сути - Sea и Land это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы"
В итоге у финальная модель данных кейса "Сказка о рыбаке и рыбке" сложилась следующим образом
Информация - это различие
Кант давно уже говорил, что этот кусок мела содержит миллион потенциальных фактов (Tatsachen) , но лишь очень немногие станут подлинными фактами, воздействуя на поведение сущностей, способных реагировать на факты. Вместо кантовых Tatsachen я бы употребил слово различия и заметил бы, что количество потенциальных различий в этом меле бесконечно, но очень немногие из них станут эффективными различиями (т.е. единицами информации) в умственном процессе некоторой большей сущности. Информация состоит из действенных различий.
Грегори Бейтсон, "Разум и природа. Неизбежное единство", 1979г.
