Как создать коммерчески успешное отраслевое решение

06.07.17

Управление проектом - Кейсы проектов

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

Понятие успешного продукта

 

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

 

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

 

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

 

Доходы, расходы и инвестиции: какими они бывают

 

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

 

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

 

Простая статья затрат – это амортизация оборудования. Тут ничего интересного нет, прямые инвестиционные затраты. Разработчикам надо где-то работать, им нужно что-то покупать, создавать условия.

 

Косвенные затраты, типа зарплаты управленцам. Тут тоже всё понятно. Это в  общий котел.

 

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

 

Теперь о доходной части. Берем классику жанра: мы разработали продукт, создали объекты интеллектуального права, начинаем использовать его с целью получения выгоды. Что мы делаем? Мы реализуем лицензии, простые неисключительные лицензии на использование результатов вашего интеллектуального труда. Это первая статья дохода. Некоторые еще делают лицензии не разовые, а пролонгируемые, то есть лицензии, ограниченные во времени. Тогда ещё одна статья появляется – доход от продления лицензии.

 

Вторая большая статья дохода – это возмездное оказание услуг по техподдержке, ИТС.

 

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

 

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

 

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

 

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

 

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

 

Если посчитать, в среднем на лицензии от стоимости проекта внедрения в хорошей отраслевой конфигурации приходится 10% доходов. Всё остальное – это услуги, та самая добавленная стоимость, ради которой трудится пул не последних разработчиков.

 

Зачем нужно разрабатывать новое отраслевое решение именно вам

 

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

 

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

 

Итак, вариант с теплым морем не получится.  А для чего же тогда мы вкладываем миллионы в отраслевую разработку?

 

Первое, самое простое и понятное – мы упрощаем себе вход к отраслевым клиентам. Представьте себе сегменты, в которых 1С традиционно не сильна. Ну, например, хорика. Кто знает более одного продукта для гостиниц на 1С? Наверное, таких мало, потому что в этой отрасли 1С не расценивается как система для установки на фронт. Это факт, реальность, данная нам в ощущениях. Представьте, что приходит в одну из гостиниц классический франчайзи и предлагает «допилить» бухгалтерию, сделать форму для регистрации гостей и многое другое, чтобы всё у вас стало хорошо. Как вы думаете, с ним будут разговаривать? Скорее всего, согласятся на помощь при сдаче баланса, не более, а для непосредственной работы установят программу шелтер или что-нибудь другое. Если мы приходим с продуктом, нас хотя бы выслушают, посмотрят продукт. Если продукт окажется действительно хорошим, есть все шансы выйти на этого клиента, выйти на него с заказной разработкой нереально.

 

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

 

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

 

Еще один плюс – сокращаются издержки при работе с клиентом. Услуги  услугами, но с очень многими отраслевыми клиентами почасовой подход не работает. Им надо сразу дать коммерческое предложение, потому что по мере реализации проекта вы не сможете маневрировать, не можете сказать клиенту: «Ты знаешь, я вот здесь планировал 20 часов, а получилось 30. Доплати еще». Он скажет: «Извини, контракт». Соответственно, закладывая отраслевое решение, вы уже сразу экономите свои затраты. Плюс ускорение работы, потому что многие клиенты в принципе не приемлют длинных циклов внедрения, им надо «вчера», поэтому проще представить готовый продукт.

 

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

 

Изменения, которые появятся одновременно с проектом

 

Согласно классической модели управления и маркетинга, у нас появляется 4п: процесс, продукт, персонал, проект. Вы меняете одну составляющую, например, продукт. То есть вы до сих пор оказывали услуги по внедрению типовых конфигураций, по проектам системной интеграции, но теперь ваш продукт поменялся, в продукте появилась ваша составляющая. Как вы думаете,что еще изменится? Я отвечу: изменится кардинально все. Персонал:в компании: появятся новые роли и специалисты, например, продакт-менеджер, которого раньше не было, и он был не нужен. Процесс: появится много новых интересных процессов, о которых раньше никто не знал, и поначалу вас будет очень сильно колотить об этих процессов. Но никуда не деться – они есть. Естественно, изменится проектная сетка: нужно будет постоянно выделять проектное ядро, придется к нему давать какое-то усиление для выполнения локальных задач, предстоит управлять одновременно проектами внедрения и синхронизации. В общем, разработка будет, как я это называю, брендзоветь. И теперь команда начнет несколько презрительно относиться к тем, кто бегает по клиентам, а в целом в компании появятся очень интересные бизнес-процессы.

 

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

 

  1. Первая ситуация: у вас есть суперклассная команда, которая может сделать любые конфигурации. Одного этого недостаточно. Если у вас она есть, написать конфигурацию – это, наверное, самое простое, что можно сделать.

 

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

 

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

 

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

 

Дальше нужна методология, опыт надо систематизировать. Когда к вам обратился один клиент, второй, третий, вы начинаете вырабатывать некую модель бизнес-процессов, модель архитектуры, которая тестируется на этих клиентах. Через какое-то время вы начинаете понимать, что уже знаете, как решить проблемы клиентов с наименьшим сопротивлением. Вот это и есть то самое ноу-хау! Как это часто бывает: вы получаете очередной заказ, тематический, отраслевой. Клиент хочет странного: он хочет эту задачу решить так, как сам представляет ее решение, например, так, как он решал ее в семёрке или ещё какой-то исторической системе, а теперь он ставит техническое задание, чтобы вы это сделали, условно говоря, в новой восьмерке. Так вот если вы ему выдаете какое-то методическое решение, если вы ему продаете его, и он согласится, если ваше решение проходит, утверждается, и в итоге превращается в работающую систему, то вот тут уже можно с уверенностью сказать, что вы готовы к тому, чтобы сделать свой собственный отраслевой тиражный продукт.

 

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

 

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

 

Я выделяю четыре составляющих в компетенциях:

 

проектный опыт;

 

теоретические знания;

 

методические решения – те самые ноу-хау;

 

связи с отраслевыми экспертами.

 

Соответственно, это нужно в себе выращивать и оберегать как самую главную ценность.

 

Какой продукт будет успешным на рынке

 

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

 

Как это сделать? Первое, с чего надо начать, – понять аналоги и конкурентов, и заменитель. Исследуйте рынок, смотрите, какую задачу заказчика, потенциального вашего пользователя, вы решаете, как он решает ее сейчас без вашего продукта. Если есть конкуренты – хорошо, вы не выходите на пустой рынок. Поэтому в данном случае все более-менее просто: надо всего лишь сделать продукт, который как минимум не уступает ни одному из конкурентов и превосходит их там, где они наиболее слабы. Если конкурентов нет, надо смотреть на аналоги и заменители и считать, во сколько они обходятся вашему клиенту. Если вы ничего на рынке не нашли, подумайте еще раз: вы делаете уникальный, не имеющий аналогов продукт, возможно, он никому не будет нужен.

 

Требования к продукту: кто их определяет и какие они? Когда вы работаете на конкретного заказчика, всё понятно, обычный цикл работы с требованиями. Кто определяет требования в отраслевой тиражной разработке, если пользователей пока нет? В этом случае надо прибегнуть к такой штуке, как пилотный проект, пилотный клиент. От того, какого вы пилота получите одним из первых, от того и будет зависеть очень многое. Чем раньше вы получите пилота, тем меньше риск в вашем проекте. Правда, тут есть нюансы. Дело в том, что участвовать в пилотных проектах для бизнеса противоестественно. Я считаю, что IT-директора, да даже генерального директора, который принял участие в автоматизации критичных для компании процессов в рамках пилотного проекта, надо увольнять, притом увольнять с волчьим билетом, чтобы потом  никто никуда не взял. Потому что это гигантские риски, которые нельзя нести. Но как разработчик, я  понимаю, что ему надо памятник поставить при жизни из жёлтых коробок 1С. Потому что именно благодаря этим людям создаются хорошие продукты. И почему они это делают? Здесь деньги не являются мотивирующим фактором. Бывают ситуации, когда нет выбора, но это мнимая ситуация, потому что нет выбора - это значит, что аналог-заменитель стоит многократно дороже тех рисков, на который идет клиент. А вообще, все пилоты, которых я знаю, они все авантюристы. По складу ума, по характеру они творцы, но вынуждены работать на таких работах, где места творчеству особо нет. Например, задачи IT-директора– управлять изменениями по части IT, синхронизировать их с бизнесом. Работы творческой немного.Поэтому для них основная мотивация участия в пилотных проектах – это их самореализация.

 

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

 

Итерационность и  инкрементирование. Если речь идет о каком-то заказном проекте, здесь более-менее всё просто и понятно. Когда мы говорим о собственном продукте, эти два требования касаются его жизненного цикла. Есть пять стадий жизненного цикла продукта от рождения до его смерти, есть определенный ритм, с которыми проходит  цикл имплементации. Хороший продукт от плохого отличается качеством методической проработки, качеством заложенных в него ноу-хау и тем, насколько выбранная архитектура соответствует методической модели. Если этого качества недостаточно, то пять шагов жизненного цикла продуктпроходит очень быстро. Это так называемый синдром второй версии, когда он может пройти все этапы за год. Говорят, сделали первую версию, а  тут что-то поменялось, и мы немедленно начали работать над второй. Что это такое? Это значит, первая версия быстро-быстро пробежала, умерла, а в это время начала зарождаться вторая версия. У хорошего продукта, коммерчески успешного продукта жизненный цикл 5 лет минимум, а лучше 10. Добивается это глубиной методической проработки.

 

Управление содержанием. Здесь я хочу напомнить о том, что коммерчески успешный продукт отличается от всех остальных тем, что он постоянно развивается, постоянно идет за рынком. Он собирает всё-всё-всё: рыночную конъюнктуру, то, что сделали конкуренты, будущие прогнозы, он себя включает в себя даже то, что клиенту вообще не надо, но о чём пишут в каком-то там научном журнале.  И чем живее продукт, чем чаще в него попадают какие-то вещи, которые исследуются на рынке, тем этот продукт увереннее себя чувствует на рынке и приносит больше выгоды своему автору.

 

Во сколько оценить свой продукт

 

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

 

Что же влияет на цену? Прежде всего, ценность – это цена, которую платит заказчик за решение задачи, а не то, сколько он платит за ваш продукт. Если ваша цена соответствует ценности, он выкладывает ее, не задумываясь.

 

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

 

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

 

Конечно, эластичность спроса. Но об этом можно почитать в любом учебнике по экономике.

 

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

 

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

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Импортозамещение. Перевод промышленного предприятия с M3 Infor на 1С:ERP за 2 месяца по технологии SCRUM

Кейсы проектов Бесплатно (free)

Когда проект ограничен по времени, и уже через два месяца заказчик физически не сможет работать в старой системе, нет времени обкладываться бумажками – нужно быстро подготовить новую систему к переходу. Расскажем о том, как гибкие технологии SCRUM и ТБР помогли за два месяца адаптировать 1С:ERP под существующие бизнес-процессы компании.

07.02.2024    2554    0    izybaevda    18    

16

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2771    0    1СERP    21    

31

Управление проектами при разработке мобильных приложений

Кейсы проектов Бесплатно (free)

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

12.09.2023    1021    0    chat007    0    

5

Как мы сделали крупнейший международный проект 1С:ERP

Кейсы автоматизации Кейсы проектов Кейсы продуктов Бесплатно (free)

В управлении проектами нет однозначных рецептов, особенно при взаимодействии с заказчиком из другой страны и другой культуры в проектах перехода из принципиально другой исторической системы. Расскажем об истории крупнейшего международного проекта перехода с SAP на 1С:ERP.

01.09.2023    1647    0    olegminkov    2    

8

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

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

05.07.2023    14301    0    ASchekachev    37    

55

Радио "Аналитик", выпуск 18. О мифах, которые рождаются вокруг продуктов с Алексеем Чернышовым

Кейсы проектов Бесплатно (free)

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

15.05.2023    534    0    Radio_Analyst    0    

1

Переход с УПП на ERP. Сложности выверки регламентированного учета при «плавном переходе»

Кейсы проектов Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

На конференции Infostart Event 2022 Saint Petersburg выступил генеральный директор компании MoscowSoft Сергей Сорокин. Он рассказал про актуальность проектов перехода с УПП на ERP, рассмотрел риски при переходе и типовые сложности, которые возникают при сопоставлении документов и других объектов конфигураций.

05.05.2023    2622    48    primat    0    

9

Как мы «завалили» проект SaaS ERP-системы за 0,5 млн евро

Кейсы проектов Бесплатно (free)

Не стыдно иметь опыт провальных проектов. Стыдно не делать выводов из провалов и не улучшать свои подходы к работе. На конференции Infostart Event 2021 Moscow Premiere Илья Отькало рассказал об уникальном проекте создания SaaS ERP-системы для туроператоров с многоканальной схемой дистрибуции, который, несмотря на вложение полмиллиона евро, все-таки пришлось закрыть.

30.03.2023    4858    0    otkalo    4    

13
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. gradi 5 06.07.17 09:07 Сейчас в теме
В целом статья интересная. Спасибо.
2. v3rter 06.07.17 09:48 Сейчас в теме
если на рынке есть хорошо работающие конкуренты, надо смотреть на их цены и назначать ее чуть *выше*.
Неожиданно.

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

И есть ещё один аспект в области конкуренции: в случае удачного выхода и серьезной конкуренции крупные игроки могут попытаться перекупить разработку или применить административный ресурс. Слишком успешный старт повышает некоторые риски )
Serg_Tangatarov; PAVI; +2 Ответить
3. pm74 199 06.07.17 09:52 Сейчас в теме
(0) неплохая статья , а насчет
Потому что, даже если он украдет продукт, что ему с ним делать?
выложит на рутрекере естественно
4. v3rter 06.07.17 09:58 Сейчас в теме
(3) Именно поэтому дорогостоящие программы сложны в применении, заумны и полны подводных камней - доля стоимости программы в общей стоимости ее внедрения не так уж и велика.
5. pm74 199 06.07.17 10:03 Сейчас в теме
(4) именно поэтому , даже если вы напишете свою "нетленку" через месяц может появиться такая же но "с перламутровыми пуговицами"
6. v3rter 06.07.17 10:28 Сейчас в теме
(5) А лет через пять обе коммерчески "невзлетевшие" нетленки перестанут запускаться на очередной версии винды )
7. pm74 199 06.07.17 10:34 Сейчас в теме
(6) поэтому отраслевки пишутся в основном как надстройки над тиражными решениями

где и заумностей и камней навалом
8. Steelvan 302 06.07.17 11:03 Сейчас в теме
кейсы и референсы = варианты применения и примеры внедрений.

Совсем русский язык забыли.
Olenevod; m191; mr.lynx; zqzq; PAVI; корум; brr; chng; cdrw3; +9 Ответить
9. Константин С. 665 06.07.17 11:57 Сейчас в теме
Эта тем нравится в таком изложении:

Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
Deslime; Dementor; _Sedoy; IvanovAV; herfis; ifilll; PAVI; корум; brr; Mi4man; pavlov_dv; fancy; kurpyaev; Yashazz; v3rter; +15 Ответить
10. Yashazz 4709 06.07.17 16:53 Сейчас в теме
(9) Именно. Подавляющее большинство т.н. "коммерчески успешных" (а точнее, просто хамски впаренных и пропиаренных) решений - ужасающее говно. По архитектуре, по эргономике, по коду, по масштабируемости... В свете этого становится понятно, откуда на рынке труда множество "внедренцев", каждый из которых мнит себя супер-программером и хочет дофига бабла, а сам ни черта не умеет даже на студенческом уровне. И так прокатит. И пипл схавает.

Искренне желаю таким "васям" разбиться всмятку. Потому что их говнокод разбирать приходится нам.
Olenevod; DJ_Codebase; IvanovAV; Yakud3a; chng; Cерый; Solovyeff; d4rkmesa; +8 2 Ответить
11. Mi4man 173 07.07.17 08:47 Сейчас в теме
(10)
Потому что их говнокод разбирать приходится нам.

Сами купили - сами разгребайте. Все логично.
Bassgood; +1 Ответить
15. ifilll 10.07.17 11:29 Сейчас в теме
12. v3rter 07.07.17 11:27 Сейчас в теме
Добавлю, что автоматизация далеко не всегда выгодна, бывает, что расходы на админов, программистов, серверную, обучение/обновление сотрудников съедают весь профит от внедрения системы и даже вгоняют в убытки. Кроме шуток.
13. корум 287 07.07.17 12:47 Сейчас в теме
(12) и тогда народ начинает включать мозг и оптимизировать работу без компьютеров.
Вспоминают бережливое производство и клиентоориентированность, а на полученные деньги можно и компьютеризацию провести.
16. ifilll 10.07.17 11:36 Сейчас в теме
(12) Автоматизация всегда выгодна если другие ресурсы для оптимизации исчерпаны.

ИТ дорого только в том случае когда её потенциал не используется, в остальных случаях она не может быть дорогой, ведь это инструмент.
14. PAVI 1388 08.07.17 08:52 Сейчас в теме
Парадокс 90% случаев автоматизации, в том числе и по отраслевым решениям), что внедрение нового программного продукта начинают, когда на предприятии уже очень плохо с деньгами и с временем на исправление того положения, в котором оказалась компания вместе с владельцем.
Dragonim; корум; v3rter; uri1978; papami; abasovit; +6 Ответить
17. ifilll 10.07.17 11:40 Сейчас в теме
(14) Сейчас такая тенденция стала уменьшатся, но это ИМХО.
18. inf012 10.07.17 11:58 Сейчас в теме
Вообще возможно выжить разработчикам на даже успешных программах?
Ведь в индустрии 1с часть денег достается внедренцам, а разработчики получают только прибыль с продажи коробок? Нет?
на чем еще живут именно разработчики помимо продаж коробок?
если рынок ограничен, тогда много продаж в принципе не возможно.
что тогда?
19. Константин С. 665 10.07.17 14:29 Сейчас в теме
(18)
Вообще возможно выжить разработчикам на даже успешных программах?

они делают просто пишется софт/документация, что без помощи не разобраться. И разработчик начинает снимать сливки, как внедренец. Любая консультация за деньги. Даже были случаи ошибочный код не исправляли, больше года. Хотя признали ошибку и получили корректный код.
Это заметно на узкоспециализированных конфигурациях.
20. inf012 10.07.17 14:42 Сейчас в теме
(19) То есть, получается, что не от хорошей жизни так делают.
В статье и вообще под термином "коммерчески успешный продукт" что значит?

Что можно заработать себе на н-лет на продаже коробок?

В течении какого времени он кормит разработчика?
Какие еще есть источники дохода?
Фирму 1С, например, еще "кормит" подписка ИТС, а тут?
21. Константин С. 665 10.07.17 15:25 Сейчас в теме
(20)
Какие еще есть источники дохода?
Фирму 1С, например, еще "кормит" подписка ИТС, а тут?

Ага продавать заведомо некорректон рабочий софт.


Ну пример успешного продукта франчевой разработки считаю "1С:Управляющий". Достойная конфа, в развитие принимали ошибки/пожелания/прочее.
22. IvanovAV 132 10.07.17 22:17 Сейчас в теме
Вначале создать и всем впарить, висящий тормозной шлак, с идиотическими алгоритмами, запросами по 5 тыс строк кода, огромной структурой измерений регистров, а потом массово продавать курсы по оптимизации этого шлака, а также обучению по настройкам этого шлака. Документацию теперь можно по пол года не печатать, чтобы никто ничего не понял и не нашел. Ввести пару платных экзаменов, на аттестацию. Да еще добавить в конфу, 100500 объектов и реквизитов с префиксом "удалить", и после каждого обновления их пополнять. Запускать обработки, которые после обновления типовой конфы , уже в режиме предприятия, по 12-14 часов данные перелапачивают, из таблицы с "удалить" в новую такуюже таблицу переносят. Можно еще много чего перечислять. Тех поддержку которая по 2-3 недели не отвечает, а если и отвечает, то ссылками на сайт ИТС, не вникая в суть проблемы.
ИМХО разработка простой и безотказной конфы под конкретного клиента (на 200 -300 объектов, 20-40 отчетов), это наше все...А типовые конфы пусть идут туда - откуда пришли.
wolfsoft; inf012; +2 Ответить
23. PAVI 1388 11.07.17 09:11 Сейчас в теме
(22)
ИМХО разработка простой и безотказной конфы под конкретного клиента (на 200 -300 объектов, 20-40 отчетов), это наше все..

Да, это путь гениев. Жаль, что гениев маловато. Да и при ближайшем рассмотрении заявка на гения может оказаться тем же "тормозным шлаком" ... Это просто мой 20-летний опыт)))
Danil.Potapov; Bassgood; корум; +3 Ответить
24. IvanovAV 132 11.07.17 20:48 Сейчас в теме
1) Бизнесу нужно простое и понятное решение его проблемы, на раз два три. Если решение сложное и непонятное, реальный бизнес найдет его у конкурентов.
2) Из последних приколов, справочник КлассификаторБанковРФ переименовали в КлассификаторБанков, типовой обмен перестал работать, бизнес несет убытки, и ищет кому выставить судебный иск об издержках и простое, сопровожденцы от франча осаждают техподдержку 1С в поисках актуальных релизов и актуальных правил обмена. Короче ИБД полным ходом и все при деле.
3) Наша самописная конфа, обменивается с типовой БП 2.0 через простой текстовый файл, работает как часы и более 5 лет обмен не требует внимания к себе.
По функционалу в ней внедрены ССП (система сбалансированный показателей), расчет сдельной оплаты труда по KPI, производство, фасовка, обмены с клиентами и поставщикам, автоматическое формирование заказов поставщику по статистическим данным прошлого периода, расчет веса под ж/д вагон, распределение затрат, самостоятельные ЦФО, когда отдел бухгалтерии выставляет внутренний счет за свои услуги отделу продаж и т.д. Весь учет по МБА. Подсистема доставки с GPS координатами и расчетом оптимального маршрута, и загрузки веса/обьема автомобилей. Обмен с сайтом на битриксе, сейчас сильно жалеем, что не написали свою CMS, а связались с глючным битриксом, и многое другое.
А самое главное все это релизовано на ФАЙЛОВОЙ базе 7.7, на 12 регистрах накопления, и 40 документах. Размер базы 800 метров!!! Одновременно работают 40 пользователей в терминале и никто никогда не виснет!
25. АльфаАвтоПрограммист 12.07.17 08:22 Сейчас в теме
(24) Где-то я это уже слышал))
по п.3:
1) Объем трудозатрат и денег на создание такой супер базы?
2) Объем трудозатрат и денег на поддержку в месяц?
3) Вы 5 лет назад сделали клиенту базу на 7-ке?
Если все секретно - то стоимость говорить не надо))

по п.2: обычная унификация. А вот что без предупреждения и осознания последствий - это косяк. Но могу сказать, это стандартная проблема программистов в отрыве от контроля методистов-консультантов.
26. genayo 12.07.17 08:27 Сейчас в теме
(24) На скольких предприятиях она внедрена, сколько лет разрабатывалась, и сколько человекочасов на нее потрачено? Я, конечно, не против качественных самописок, но вот не тиражируются они в 99% случаев.
27. TODD22 18 12.07.17 08:32 Сейчас в теме
(24)
что не написали свою CMS

А так же напишите свою операционную систему или сразу спаяйте свой компьютер... Делов то....
никто никогда не виснет!

Да ладно? В 7ке и никто не виснет? Как вы решили проблему с захватом таблицы? Когда все начинают вылетать с ошибкой транзакции и всем приходится выходить из программы и заходить заново что бы снять блокировку с таблицы? Я сам не 7шник. Но вот есть такая проблема. Пользователи начинают проводить документы и им выдаёт ошибку транзакции. Лечится только выходом всех пользователей из базы.
28. корум 287 12.07.17 11:08 Сейчас в теме
(27)
Я сам не 7шник. Но вот есть такая проблема.

Для начала стоит попробовать ананасы ;)

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

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

в мире 7.7 не так беспросветно-ужасно, как тебе кажется :)
29. TODD22 18 12.07.17 11:31 Сейчас в теме
(28)
В обычном случае "ошибка транзакции" лечится ... повторным нажатием на кнопку ОК.

Да вот почему то не лечится. Только выходом всех из базы и повторным заходом.
30. корум 287 12.07.17 11:34 Сейчас в теме
(29) Так уж и всех?
Мне помогало отрубание самых "нажористых".
1-2 сессии снимал, работа остальных приходила в норму, и уже без аврала можно разобраться, что это было...
31. artbear 1448 12.07.17 13:03 Сейчас в теме
(29) Позовите профессионала-семерочника, он поможет решить эту проблему.
На семерке в свое время у меня и 100 пользователей работали, а у коллег и того более.
корум; IvanovAV; +2 Ответить
32. IvanovAV 132 12.07.17 14:01 Сейчас в теме
Друзья, я четно не ожидал, что вызовет такой ажиотаж мой пост. Постораюсь ответить на все вопросы.
1) Вы правы на 100%, эта самописная база на 7.7 совсем не успешная коммерчески, (в отличии от успешных типовых поделок 1с) т.к. узко допилена под конкретного клиента. Директор закончил курсы МБА, и вел разработку по своим методикам. Изначально все новые алгоритмы обкатываются в экселе, а я чисто как исполнитель, занимаюсь автоматизацией экселя. Пользователям все просто и понятно, никаких сложных алгоритмов, типа РАУЗа и т.д там нет.
2) База пишется с 2005 года, я работаю на этом проекте с 2009 года, в среднем 35 часов в месяц, около 40 тыс руб в мес. Это тех поддержка + постоянная разработка нового функционала. Очень много сил прикладывает сам директор и руководители подразделений, я только исполнитель. Выручка фирмы несколько млн руб в день, больше тысячи документов в день.
3) С взаимоблокировками решили проблему, разделением прав. В справочнике пользователи, много галочек, каждая галочка прописана в процедуре ПриОткрытии обьекта. В результате каждый пользователь работает только с теми участками базы, которые ему нужны, вплоть до реквизитов документа, поэтому пользователи не пересекаются. Этот механизм хоть и мудреный, но работает в разы быстрее хваленого RLS в восьмерке. Также жестко разделены отчеты, для каждого подразделения.
4) Битрикс не любим потому, что писали его под себя, за 2 года вложили в него 1,5 млн руб, и постоянные проблемы, которые крупная московская студия, решает совсем не оперативно, наш директор не хочет менять коней на переправе. В битриксе у нас поднят почти весь функционал 1С, сайт B2B, клиент в личном кабинете видит, свои взаиморасчеты, сам делает акты сверки, видит свою колонку цен, на сколько нужно докупить чтобы перейти в другую категорию, пишет жалобы, есть свой блок СРМ, статусы заказа, оплаты и доставки и много другое.
4) На прошлой недели ребята с инфостарта помогли и подключили он-лайн касссу по 54 ФЗ.
5) Сейчас ищем мобильное приложение под курьерскую доставку, и пробитие чека на кассу по блютузу, такое приложение есть у фирмы МойСклад, думаем как его прикруть или у кого заказать аналогичное решение.
33. TODD22 18 12.07.17 14:55 Сейчас в теме
(32)
и постоянные проблемы,

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


(31)
На семерке в свое время у меня и 100 пользователей работали, а у коллег и того более.

Так проблема не в производительности. А в том что в какой то момент у всех вылетает ошибка транзакции и помогает только выход и повторный вход в базу всех пользователей. Проблема возникает где то на одном пользователе. Но не понятно на каком и не понятно кого выгонять.
Проблема не частая но раза 2-3 в месяц попадаем на неё.
Светлый ум; +1 Ответить
Оставьте свое сообщение