Управление предприятием во времена кризисов

Некоторое время назад я опубликовал рассуждения на тему заказа презентации тиражного программного обеспечения. Подразумевалось, что продукт предлагается “почти готовым к употреблению” и объем требуемых доработок, с одной стороны, хоть как-то прогнозируем, и, с другой стороны, является одной из важных тем дискуссии в ходе презентации.

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

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

Где получить такие сведения?

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

Направления обозначены выше:

1. Поставщик
2. Продукт

Соберите все возможные данные об истории и текущем положении фирмы на рынке и составьте краткое резюме на полстраницы.

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

Затем составьте список вопросов, ответы на которые подтолкнули бы вас к выбору продукта для автоматизации собственного бизнес-процесса.

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

Думайте широко, но на презентации спрашивайте конкретно

Вы когда-нибудь занимались контекстной рекламой программного обеспечения?

Вот я - занимался. Не имея никакого практического опыта.

Итог, мягко говоря, малоутешительный.

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

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

А во-вторых, необходимо всемерно с этого трафика конверсию повышать.

Так я вам скажу, что конверсия с запросов а-ля “CRM” будет никакая…

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

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

Только SEO - это небыстрое дело, и контекстная реклама используется на первом этапе привлечения клиентов обязательно. Использовать ли ее потом - вопрос эффективности.

Совет здесь может быть только один, вернее, два, но похожих.

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

…А вы как вообще, готовы обработать поступивший звонок или входящее письмо? План работы с новым клиентом есть?..

Иначе все эти рекламные ухищрения никому не нужны.

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

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

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

Преимущества таковы.

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

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

• отсутствие корпоративной культуры разработки и документирования (если кто-то не принес ее с собой)
• отсутствие (обычно) буфера между заказчиком и разработчиком в лице разнообразных менеджеров, кураторов, директоров и прочих

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

Так стоит ли участвовать в разработке, скажем, CRM-системы с нуля?

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

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

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

Вы можете заказать обзор своего продукта у меня, а можете прислать готовый текст для размещения. Все рекламные материалы (и оплаченные мои обзоры тоже) в обязательном порядке (если я не забуду) помечаются лейблом “НА ПРАВАХ РЕКЛАМЫ”. А чего вы хотите, это же не дняффка, а профессиональный блог.

Я, само собой, с удовольствием отказываю тем, кто прославился на рынке неадекватным поведением и отношением к потребителю Остальным, особенно авторам новых программных бизнес-продуктов - велкам!

82898ccc250bf95b1c00e911a1fbe248

Внесение изменений в работающее ПО: протоколирование справочников

Картинка из жизни. Интересно это будет тем, кто занимается оперативным учетом. (А чем еще в сегодняшнем бизнесе стоит заниматься? Уж не моделированием ситуаций, наверное).

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

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

Каковы могут быть варианты решения?

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

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

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

Хуже того - по-хорошему надо бы реализовать протоколирование и того, и другого.

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

Это если нет концепции реализации версионности записей.

Касательно документов - реализованная правильно система хранения версий тоже была бы нелишней.

Я в задумчивости.