Хочется ругаться

Такое впечатление, что живешь на Луне – хоть бы кто-то прокоментировал документы стратегии.
Стратегия управления ассортиментом и запасами.
Есть спорные вопросы по управлению ассортиментом. Их можно обсудить с Зоей, Таней и Машей.
По запасам всё гораздо сложнее. Или кто-то из сотрудников за неё возьмется (над этим работает? Настя) или надо ждать пока я закончу «Мозг фирмы» и начну ограничивать разнообразие входящей информации. Последний путь – избыточен. Можно попробовать поговорить с участниками проекта Управление запасами.

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

Стратегия региональных продаж.
Идей никаких. Нужна встреча с АндреемЗ и АлексеемИ.

Неделя 48/2007

Стратегия.
В описании стратегии сделаны разделы «Управления ассортиментом и запасами» и «Расширение сети ЛапУсик". На этой неделе можно:

• обсуждать первую из стратегий с отделом логистики или готовить процессную модель(желательно)
• вторую «доносить» до отдела розничных продаж (встреча продавцов – обязательно).

По региональным продажам – никаких идей. Но дан старт проекту региональных продаж и может благодаря ему идеи появятся.

Корпоративные проекты.
Из корпоративных проектов ограничусь:

• Обустройство склада 2007. Прошлая неделя – переосмысление этого проекта. Надо добить заказ на Авилон. Наверное будет ещё встреча по стеллажам.
• Каталог товаров – надо передать техзадание программистам. Хотя бы Геннадию.

Прочие проекты и программы
По работе комитета по сайтам пройден очередной этап – получено согласие на круг задач комитета от СергеяБ. Следующий шаг – согласовать процедурs работы комитета. Для этого документ site@lessi:АлгоритмРабот дополнить алгоритмом принятия решений в комитете и согласовать его с СергеемБ. С этой работой хотелось бы закончить поскорее. Я дочитал книгу «Мозг фирмы» и мне хотелось бы переделать документ management@lessi:СистемаУправления

Отдел, оргвопросы, инструменты
У Светы проект по суши-бару. Ей нужна будет моя помощь.
Мне предстоит помогать Тане, и, возможно, Зое в начале работы.
С Настей – работа на ставку.

Вопросы для обсуждения по комитету site

Для работы комитета в режиме «сопредседателей» надо решить следующие вопросы:

1. Что входит в компетенцию комитета
2. Каков принцип организации работ в комитете
3. Каков принцип принятия решений в комитете
4. Границы публичности работы комитета

Это далеко не все вопросы, которые у меня есть. Кроме того, можно просто начать, а решения принимать по-ходу. Но лучше, ИМХО, хоть о чём-то договориться.

Мои предложения по этим пунктам.

1. Пока ограничиться минимумом:
   • сайт lessi.com.ua и его подсайты, все веб-сервисы расположенные на этих сайтах,
   • сайты korm.com.ua и zooshop.com.ua, все веб-сервисы расположенные на этих сайтах,
   • все сервисы доступные в нашем хостинг-пакете от. REDO (в частности, почтовый сервер)
   • сервер находящийся на коллокейшн в дата-центре Воля
   Если эксперимент по работе через комитет себя оправдает, то компетенция комитета может быть расширена до «ИТ-инфраструктура компании в Интернет и протоколы Интернет». В частности, вопрос использования ICQ пока находится в компетенции ФИС и не переносится в комитет.

1. Работа в комитете строится по следующим принципам:
   1. Все проблемы и идеи в работе сайтов и пр. фиксируются в виде рапортов в баг-трекере
   2. Участники рабочей группы вправе брать на себя инициативу по решению отдельных вопросов из баг-трекера ни с кем не согласовывая
   3. Обновление сайтов и веб-сервисов происходит через выпуск релизов. Релиз это документ, представляющий собой список задач, который позволяет координировать работу нескольких человек в одном направлении:
      • В релизе должна быть заложена некая идея вокруг которой строится выпуск релиза
      • Эта идея формулируется сначала в виде преамбулы (текстового описания), затем в виде списка обязательных задач для релиза,
      • К идее релиза не имеют отношения исправления ошибок (но при этом они имеют высокий приоритет) и отдельные задачи (которые имеют низкий приоритет), хотя если мы делаем релиз одного сайта, то к нему скорее всего не имеют отношения ошибки другого сайта
      • В релиз могут быть заложены только задачи, решение которых уже сформулировано (как правило – в виде комментариев к рапорту в баг-трекере),
      • Все задачи релиза должны иметь ссылку на соответствующий рапорт в баг-трекере,
      • Работа над релизом продолжается до тех пор, пока не будут выполнены основные задачи релиза
      • В работе может находится только один (но не менее одного) релиз; сколько угодно релизов (но не менее одного) могут находится в обсуждении.
      Есть целый ряд случаев, когда эти принципы нам будут мешать. В частности – я не могу начать работать над релизом 1.2 (идея которого – запустить korm.com.ua), пока не закончу релиз 1.1, который сейчас «в работе». Более того, я не могу считать целью релиза 1.2 «запустить korm.com.ua», т.к. в этом направлении ещё ничего не ясно (решение для задач не сформулировано), а релиз 1.1 вот-вот закончится и я буду вынужден начинать новый релиз.
      Кроме того, не ясно где заканчивается программная работа и начинается проектная. Вариант решения: программная – работа своими силами, без привлечения дополнительных ресурсов, проектная – с привлечением дополнительных ресурсов.
      Не ясна так же роль (права и обязанности) Руководителя релиза, участников РГ.
      Документ, который описывает правила работы для комитета – site@lessi:АлгоритмРабот. В нем нет раздела связанного с п.2 – когда я его писал идеи «сопредседателей» ещё не было.
2. Предлагается принцип «согласия обоих сопредседателей». При этом не ясно, что делать, если не договорились. И является ли работа в комитете «должностной обязанностью» или «личной инициативой» – т.е. можно ли за неё спрашивать?
3. Я создавал эту рабочую группу (комитет) только ради prj.lessi.com.ua вообще и НПЖ в частности (расшифровывается, кстати, Net Project Journal – журнал проекта в сети). И мне не на кого было надеяться, кроме как на сообщество из Интернет, в частности сообщество с npj.ru. Поэтому я изначально сделал эту группу максимально открытой. Предлагаю начинать именно в таком виде. Автор отдельных сообщений и документов при этом может самостоятельно ограничить права доступа к ним. В частности это сообщение видят только сотрудники, и не увидят другие, даже если они станут участниками этой рабочей группы.

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

Неделя 47/2007

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

• сегодня с Ивановым о региональных продажах,
• в среду на тему формата пятого магазина,

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

Корпоративные проекты.

• Региональные продажи 2007 – надо сформулировать цель проекта и предложить возглавить его Иванову,
• Управление запасами 2007 – этот проект будет затронут при обсуждении кандидатур на описание модели,
• Обустройство склада 2007. Авилон дал размеры корзин для супермаркета. В пятницу сделал необходимые замеры верхнего склада. завтра будут делать замеры нижнего склада. Можно заказывать стеллажи для верхнего.
• Каталог товаров – сделал техзадание в OneNote. Надо выложить в НПЖ. И если потяну – связаться с программистом.

Прочие проекты и программы

• Бренд Лап-Усик – встречи прошли заочно. Теперь надо опубликовать 6 старых логотипов.
• Регулярный менеджмент 2007 – надо принимать какое-то решение по инструменту для публикации должностных инструкций. Но решение этого вопроса зависит от следующего пункта.
• R1.1 – описал site@lessi:АлгоритмРабот. Но если СергейБ примет решение участвовать в работе комитета, то этот документ надо будет ещё дополнять алгоритмом принятия решений в комитете.
• Движок сайта – вряд ли я смогу что-то решить на этой неделе (слишком плотный график), но получить доступ к материалам проекта надо.
• Документ Система управления. Описал уровень стратегического управления. Потребность в этом документе возникает и для стратегии. Но по логике самого документа надо начинать с Эталонного дерева функций.

Инструменты, оргвопросы, отдел

• Обсудить с Настей работу на полную ставку
• Решить вопрос с WebMoney
• Прокомментировать планы специалистов

Положение о подразделении – проект или программа?

Уже дважды (management@lessi:СистемаУправления и eduardk@lessi:28553) возникает мысль о том, что пора начать готовить положения о подразделениях. Вопрос в том, как организовать работу над этим документом?

• Вариант 1. Я готовлю свой недельный план и «добиваю» незаконченное. Проблема в том, что это незаконченное превращается в монстра, который уже не добивается вторую неделю.
• Вариант 2. Создать соответствующий проект в НПЖ и MLO. Этот путь вполне естественен – раньше эта цель была частью цели проекта Регулярный менеджмент. Теперь эти цели просто разошлись по разным проектам.
• Вариант 3. Идея этого документа вполне вписывается в направление работы комитета Управление. Тут бы его и делать. Правда меня не покидает ощущение, что комитет этот нужен лишь на переходном моменте, пока у нас не появится полноценная вики для работы над созданием и связыванием управленческих документов.
• Вариант 4. Делать базу знаний по управлению и там организовывать работу над этим документом. Этот путь не скорый, т.к. уже практически решено, что следующей программой над которой будет работать комитет site@lessi – начало работы сайта korm.com.ua.
• Вариант 5. Поручить эту работу кому-то. Но Настя сейчас перегружена, а больше поручить некому.

После формулирования этих вариантов я вижу, что надо разделить два понятия:

• где публиковать положения о подразделении,
• как организовать работу над этим документом.

Начну со второго.
Т.к. поручить некому (вариант 5), то делать придётся самому.
В своей организации времени я использую только два понятия – задача и проект (слоновая задача, программа – это лишь частные случаи проектов). Раз я уже вторую неделю работаю над этой задачей а работы только прибавляется – значит это не задача (вариант 1). Организовывать работу надо через проект. Как минимум в MLO.

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

• в своём журнале,
• создать соответствующий проект в НПЖ (вариант 2),
• в комитете Управление (вариант 3),
• делать базу знаний по управлению и там организовывать работу над этим документом (вариант 4).

Настя публикует ДИ в своём журнале. Это оправдано, т.к. она не использует в организации своей работы «проектный подход», на момент начала публикации ДИ ещё не было комитета Управление, она только начала осваивать НПЖ. Соответственно мне этот пункт не подходит.
Выбирая между вариантами 2 и 3 надо отдать предпочтение второму. Во-первых понятие «проект» никто кроме меня не использует. Создавая ещё один проект в НПЖ я только запутываю читателей. Во-вторых, Настя уже работает в комитете Управление (а она заинтересованное лицо) и не хочется усложнять ей жизнь подключая к ещё одному проекту в НПЖ. В-третьих, проект в НПЖ видимо надо создавать только если есть как минимум два участника РГ – а я пока один. Далее, не факт что это проект, а не программа в терминологии компании – дополнительные ресурсы (кроме моего времени) мы не привлекаем. Наконец, комитет можно рассматривать как место для накопления документов, которые потом будут опубликованы в Базе знаний – и лучше их накапливать в одном месте. В общем: вариант 2 не создаём РГ проекта в НПЖ.

Последний выбор – между вариантами 3 (есть) и 4 (будет). Вопрос в том когда будет?
Это вопрос конкуренции идей в рамках комитета site@lessi. Что положить в основу релиза 1.2: базу знаний по управлению, РГ для работы над каталогом товаров или запуск сайта korm.com.ua?

• РГ для работы над каталогом товаров – у меня не готово тех.задание, не выбран программист, программист не профинансирован, программист может предпочесть другой вариант организации коллективной работы.
• базу знаний по управлению – у меня всё готово (надо проверить) для старта и это для меня предпочтительный вариант – я совмещаю свою работу над релизом с работой над организацией системы управления,
• запуск сайта korm.com.ua – надо познакомиться с руководителем проекта на стороне подрядчика и услышать их планы, надо познакомиться с документами проекта, надо принять решение по менеджеру сайта и запустить его в работу. Всё это большой кусок подготовительной работы, который я могу запланировать на следующую неделю.

Правда теперь я должен этот вопрос согласовывать с сопредседателем комитета site@lessi.

Снова о стратегии. Прорыв

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

• завершить проект Обустройство склада,
• построить собственный склад за городом.

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

Среднесрочная стратегия для розничного рынка проста и понятна. Надо увеличивать число магазинов в сети ЛапУсик в Киеве (возможно в пригороде), при одновременном совершенствовании формата магазинов. Нужно инициировать проект «Магазин №5» – мы лишь ждали итогов квартала. Из наиболее интересных разработок в области формата – перенос идеи формата «зооцентр» на площадку торгово-развлекательного центра.
Если копать эту стратегию глубже, то надо говорить о реорганизации в отделе розничной торговли с целью повышения количества открываемых магазинов – нужны люди и стимулы которые бы позволили открывать несколько магазинов одновременно. Такой подход сталкивается с существенным ограничением – деньги компании понадобятся для реализации краткосрочной стратегии (свой склад за городом). Выходом видится привлечение финансовых партнёров для реализации этих стратегий.
Если разбираться далее с организационными и финансовыми вопросами, то мы, скорее всего, столкнёмся с необходимостью изменения учётной политики:

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

Среднесрочная стратегия в регионах имеет ту особенность, что мы не можем определиться с её идеей. Вот цитата из книги Стаффорда Бира «Мозг фирмы»:

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

Не знание «технологической основы» бизнеса в регионах в следующие три года это есть наше главное ограничение. Идея Сузирья о франчайзинге – это зарубежный опыт который в Украине пока не пригоден – у нас ещё нет борьбы брендов. Наиболее близким на сегодня является для нас идея «сервисной компании» (статья Юры Синицы в журнале ВетЗооПрофи). С позиции компании Лесси идея сервисной компании звучит следующим образом.

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

Сложно определить понятие «тот же уровень сервиса». Но скорее всего это:

• ассортимент,
• оперативная доставка,
• персональный менеджер (торговый представитель; важно для крупных клиентов),
• не большой минимальный заказ (300 грн через торгового представителя, 500 – грузовиком; важно для мелких клиентов),
• отсрочка платежа.

Из этих «сервисов» ассортимент у нас есть, отсрочка платежа – пока не критична. Суть стратегии продвижения в регионы сводится к выбору варианта доставки, персонального менеджера и минимальной партии. Какие у нас есть варианты, с учётом того, что мы пока ограничиваем сферу своих интересов Киевской, Житомирской, Черниговской, Винницкой и Черкасской областями?
Доставка:

• «срочная» доставка силами торгового представителя на таких расстояниях уже не возможна – Юра её использовал только для раскрутки маршрута,
• радиальные 1–2 дневные маршруты автомобилями 2–3 тоны (наш маршрут на Житомир)
• круговые 3–5 дневные маршруты автомобилями 5–7 тон (этот вариант используют Сузирье, Коллар)
• открытие регионального склада – об этом говорить преждевременно.

Персональный менеджер:

• региональный менеджер из Киева,
• менеджеры продаж на телефоне (телемаркетинг),
• торговые представители в областных центрах.

Минимальная партия:

• 300 грн (фактически у нас в Киеве),
• 500 грн,
• 1000 грн (фактически у нас в регионах),
• от ящика/мешка (для кормов).

Сначала о доставке (и минимальной партии), т.к. она, ИМХО, важнее и сложнее в организации. В Киеве мы предлагаем не просто «доставку», а «оперативную доставку». О том что именно в этом наше конкурентное преимущество говорят следующие два факта:

• нам удается «подсекать» компании, которые являются «первыми руками» при работе с оптовыми клиентами только за счёт более оперативной доставки,
• запасы товаров в магазинах сети ЛапУсик в два раза меньше запасов в магазинах Левченко (в пересчёте на метр площади) благодаря компьютеризированной системе учёта и доставке раз в два дня.

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

• гарантии наличия товара (у Сузирье ассортимент имеет ограничения, а перебои в наличии товара более затяжные),
• оперативная доставка – т.е. не менее частая чем у Сузирье и Коллара (Сузирье возит товар в Киев раз в неделю),
• не большие партии,
• доставка в любые населённые пункты.

Первый пункт мы сделаем в рамках годовой стратегии. Сюда же надо добавить использование ИТ-технологий.
Второй пункт может быть обеспечен только через короткие радиальные маршруты грузовыми автомобилями средней грузоподъемности.
Третий пункт нужна информация о партиях Сузирье и Коллар СветыД. Или хотя бы информация о просьбах уменьшить нашу минимальную партию в 1000 грн. Пока считаем сумму в 1000 грн приемлемой.
Четвертый пункт пока не работает и загвоздка видится именно в нем. Проблема ИМХО не в том, что бы найти заказы, а в том, есть ли смысл везти небольшие заказы черт его знает куда.

Вторая проблема – организационная. Кто должен продавать в регионы? Если исходить из требования «тот же уровень сервиса, что и в Киеве», то продавать должны торговые представители в регионах. Личный контакт не заменишь никаким тренингом по телемаркетингу. С другой стороны обеспечить личный контакт через менеджера продаж из Киева для клиента за 300 километров для компании будет крайне дорого.
Но к вопросу организации системы сбыта можно подходить не логически, а хронологически.

• На первом этапе надо «пробивать маршруты». И это сможет сделать только «региональный менеджер компании из Киева» который приехал поговорить «лично с Вами».
• Как только пойдут заказы (через месяц) и пока мы не решим проблему перебоев (через год) потребуются менеджеры продаж на телефоне. Не операторы, а именно менеджеры.
• Когда регион раскрутился, можно принимать на работу торгового представителя из областного центра (Житомир, ИМХО, уже созрел). Тогда он осуществляет «личный контакт» с клиентом. А компания думает как обеспечить контакт с ним.

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

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

• как (финансово) обеспечить рентабельность доставки в населённый пункт находящийся в стороне от радиального маршрута заказа в 1000 грн,
• как (организационно) нам построить подразделение в котором с одним клиентом работают разные сотрудники.

Второй вопрос – для маркетолога и менеджера по персоналу.

По первому вопросу процитирую Стаффорда Бира:

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

По порядку. ЮраМ строил маршрут в Черкассы находя потенциальных клиентов Лесси – специализированные торговые точки. И этим проектом он подтвердил правильность выбранного компанией стратегического направления – курс на доставку в регионы, возможность построить рентабельные маршруты «с нуля».
АлексейИ предлагает построить маршрут исходя из продовольственных торговых точек, в которых уже присутствуют корма. Эта идея не вписывается в избранную Лесси политику – мы работаем со специализированной розницей. Но эта идея блестяще подтвердилась историей создания компании Лесси. Мы состоялись как компания вообще и как «сервисная компания» в частности только благодаря большому количеству маленьких заказов из продовольственных магазинов.
Моё предложение заключается в том, что бы провести эксперимент (проект) по созданию регулярного маршрута на базе продовольственных торговых точек. Если он себя оправдает, то мы решим первый из двух вопросов по стратегии региональных продаж. Построив транспортную логистику по принципу Кока-Колы – много маленьких заказов в одно место – мы сможем сделать доставку в отдалённые места рентабельной и, тем самым, обеспечить взрывной рост количества маршрутов регионы. Лично я уверен, что даже на этапе роста этот путь будет вполне рентабельным. Но даже если это не так, то только имея большое количество регулярных маршрутов (построенных на плечах продовольственных магазинов) мы можем обеспечить еженедельную доставку в специализированную торговую точку где-нибудь в Кацапетовке заказа от 1000 грн.

Неделя 46/2007

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

• Ответить на вопросы склада – отвечать надо не публикациями, а Обустройством склада и Регулярным менеджментом.
• по R11 – на этой неделе можно закончить site@lessi:АлгоритмРабот и, тем самым, завершить релиз. Сделать это надо до среды – будет решаться вопрос о передаче в комитет site@lessi управление сайтом korm.com.ua.

Дальнейшие действия можно делать через группировку стратегия-проекты-программы. Стратегию я описал. Теперь проекты.
Региональные продажи. Это и проект и одна из стратегий. На этой неделе будут собеседования. По этому проекту мы выходим на то, что склад снова наше узкое место. Следующие действие в рамках проекта Обустройство склада – выяснить размеры корзины для супермаркета (склад аксессуаров).
Три проекта (Управление запасами 2007, Обустройство склада, Каталог товаров) это всё одна стратегия. По двум из них следующее действие уже названо. Третьим занимается СергейБ.

Программы.
По проекту Обустройство склада ВолодяК не захотел брать на себя инициативу (как и СветаД по проекту Бренд). Система проектного управления даёт сбой, из-за отсутствия мотивации. Если я хочу не решить отдельные вопросы, а построить систему которая решает эти вопросы, мне надо возвращаться к документу management@lessi:СистемаУправления. Сделать его окончательно я смогу только дочитав «Мозг фирмы». Но уже на этой неделе я могу описать уровень стратегического управления (строить систему управления будем с головы).

Команда на регионы

Что мы уже решили.

• Региональные продажи есть одно из трёх стратегических направлений
• Основой продвижения (идеи региональных продаж) являются продажи с доставкой
• На данный момент мы ограничиваемся Киевской, Житомирской, Черниговской и Виницкой областей
• Для развития региональных продаж необходимо создавать новое подразделение (отдел) на базе торгового зала (отдела самовывоза)

Вопросы такие:

1. Будем ли мы развивать регионы через:
   • Регионального менеджера в Киеве
   • Торговых представителей в областных центрах
   • Телемаркетинг

   К этому вопросу имеют прямое отношение вопрос готовы ли мы обеспечить в регионах такой же уровень сервиса как мы обеспечиваем в Киеве? Что входит в понятие «уровень сервиса»? Является ли персональный менеджер частью минимально необходимого уровня сервиса?

2. Сколько должно быть сотрудников в отделе региональных продаж и их функции
3. Кто будет руководить подразделением региональных продаж – АндрейЗ или другой человек
4. Как организовать оплату сотрудников в подразделении с учётом а) общей цели, б) разной работы
5. Подразделение сможет работать только при наличии грузового автомобиля, а наши 3 перегружены уже сейчас.

Курица и яйцо

Вчера на Совете обсуждался вопрос о приобретении 4-го грузового автомобиля. При этом была озвучена интересная цепочка:

Надо покупать автомобиль, т.к. работы уже есть на 3,5 машины

Автомобилю просто негде будет стать под загрузку – надо сначала развести их во времени

Уже сейчас склад получает достаточно заказов для сбора с вечера – кладовщики их не собирают

Не собирают, т.к. не хватает места на складе:

• или они заняты на разборе завалов товара
• или они соберут заказы и их некуда будет поставить

Тогда надо:

• вернуться к проекту Обустройство склада
• организовать работу склада в 2 смены

Автомобиль всё же решили покупать и продавать Газель. Но склад снова стал узким местом.

Документы проекта уже актуальны

Мы начинали работу над проектом в OneNote. Затем перенесли работу в Groove. Потом была переписка по электронной почте. И наконец теперь мы используем НПЖ.
После сегодняшней чистки:

• По прежнему самая полная копия всех документов проекта в папке проекта в файловой системе. Там лежат оригинальные файлы и их можно редактировать в родном формате.
• Там же – архивная копия Groove. Документы и картинки я оттуда достал, а вот обсуждение достать не могу. Хуже того, я даже прочесть его не могу. Надеюсь, что при необходимости переустановка Groove поможет.
• В НПЖ находится практически всё по сотрудничеству с CodEX: техзадание, их варианты изображений, переписка с Машей. Нет только обсуждений из Groove.

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

• Бренд ЛапУсик.gsa – это последняя информация, но возможно с неработающим обсуждением
• Копия Бренд ЛапУсик.gsa – это более старая версия

Где публиковать регламенты?

Это сообщение – копия рапорта site@lessi:trako/3

Надо создавать базу знаний по управлению и там публиковать должностные инструкции.
НПЖ не подходит т.к. не поддерживает следующую функциональность (акшн) вики (ещё не проверял):

• BackLinks — ссылки на данный документ – работает
• OrphanedPages — список документов, на которые нет ссылок,
• WantedPages — список документов, на которые есть ссылки, но которые ещё не созданы,
• Search — различные поиски.

Кроме того в вики можно подписаться на отдельную страницу, в НПЖ (если я правильно понял) – только стать наблюдателем в РГ

В своё время я отказался от WackoWiki в пользу НПЖ
Использовать другую вики мне бы не хотелось – сотрудникам надо осваиваться с другими правилами разметки и интерфейсами

По результатам работы в комментариях к этому сообщению был создан документ management@lessi:БазаЗнанийПоУправлению

 

Комментарии к этому сообщению:

Системы управления

Есть три системы управления:

• функциональная,
• проектная,
• программная.

В НПЖ (с помощью НПЖ) я могу организовать следующие контуры управления.
Программный
Через рапорты в баг-трекере. Непрерывное улучшение заключается в том, что жалобы и предложения рассматриваются, назначаются и решаются.
Проектный
Через создание РГ для проектов. Цели проектов это те же рапорты баг-трекера, но решить которые не возможно в рамках программного управления.

1. Отбор (выбор) цели для реализации происходит через обзор рапортов с определённым статусом с учётом приоритетов (стратегии) компании.
2. Уточнение цели происходит через комментарии к рапорту.
3. Достижение цели происходит через создание рабочей группы и выделение ей ресурсов.
4. Рабочая группа координирует свою деятельность с помощью списков задач и встреч.
5. Мотивация и публичный контроль за работой РГ может быть реализована через возможность для заинтересованных лиц стать наблюдателем в РГ.

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

 

#797 @ 23:17 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

База регламентирующих документов

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

#798 @ 23:26 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Порядок разработки и утверждения документа

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

1. должен быть баг-трекер, где накапливаются вопросы.
2. в ходе (закрытого) обсуждения (в виде комментариев) вырисовываются варианты решения – предложения на Совет.
3. в ходе Совета обсуждается уже не вопрос, а варианты решения
4. в ходе Совета происходит голосование или вопрос отправляется на дальнейший поиск путей решения

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

#799 @ 23:29 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Процесс работы с регламентирующим документом

Этапы работы с документом:

1. Подготовка
2. Согласование
3. Утверждение
4. Публикация
5. Актуализация

Всё это желательно делать в единой базе с соответствующими механизмами разграничения прав доступа и оповещениями.

#801 @ 23:33 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Разные процессы для разных типов документов

Менеджеры управляют тремя вещами:

• Политиками,
• Процедурами,
• Показателями.

Возможно это три разных типа документов, которые имеют разный процесс прохождения документа.

#808 @ 09:59 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Показатели отображаются в отчетах. Для работы с показателями лучше подходят 1С, Парус, SharePoint. Значит процесс прохождения этих документов лучше описывать там. Максимум, на что может претендовать база знаний по управлению – иметь возможность вставить отчёт в тело страницы в виде:

• таблицы,
• картинки (график),
• html

Это требуется для:

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

#809 @ 10:07 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Процедуры отображаются в диаграммах. Реже – с помощью специальных языков (Каллиграф). Хуже всего – средствами обычного языка.
Для работы с процедурами лучше подходят ARIS, BPwin, Инталев: бизнес-навигатор. Процесс прохождения этих документов можно описывать и тут, но готовить их прийдется там.
База знаний по управлению для такого рода документов должна:

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

#810 @ 10:16 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Редакторский цикл

Полный редакторский цикл для работы с документами, вне зависимости от типа информации (политика, процедура, показатель):

1. Инициация
2. Назначение
3. Подготовка
4. Согласование
5. Утверждение
6. Публикация
7. Актуализация
8. Оповещение

#802 @ 23:46 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

До Подготовки

До первого шага должно быть нечто, что инициирует (запускает) весь процесс подготовки документа.
Разработка определенного документа может быть целью проекта (например ks2006@lessi или regulman@lessi). Тогда механизмом запуска послужил рапорт и стратегия.
Разработка (скорее актуализация) отдельного документа может быть спровоцирована жалобой, как элементом программного управления.
Подготовка документ может может быть инициирована руководителем. С точки зрения программного управления – это та же жалоба в баг-трекере.
Наконец потребность в документе может возникнуть исходя из потребностей самой системы. Система функционального управления это есть связанный набор непротиворечивых документов. И если между документами не хватает связи, или есть противоречие – эту ситуацию можно исправить создав новый или отредактировав старый документ. (особенно это часто это будет происходить при обновлении одного из связанных документов – начнется цепочка изменений)

#803 @ 23:47 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

права доступа

#804 @ 23:48 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

оповещения
доведение до исполнителей

 

#805 @ 09:06 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Разберём критически

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

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

 

#806 @ 09:17 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

База знаний

База знаний может создаваться двумя путями:

• формальный (ARIS, Инталев бизнес-навигатор)
• описательный (Вики)

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

Недостаток формального метода – время отдачи. Для запуска формального метода нужны:

• специалист, который этим будет заниматься
• правильно (адекватно) выбранная методология
• значительные усилия по наполнению базы

Результат формальный метод даст, только при достаточном наполнении базы.

Стоп. Это ерунда.
Формальный метод однозначно лучше. Просто компания Лесси к нему пока не готова. Нам надо накопить некую исходную информацию, прежде чем мы начнём ее формализовать (систематизировать).
На сегодняшний день наша база знаний по управлению должна базироваться на:

• Гипертекстовых блоках страниц, полученных путем экспорта из формализованных систем,
• Вики для накопления информации.

 

#807 @ 09:30 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Архитектура системы

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

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

 

#811 @ 11:41 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Окончательный выбор в пользу WackoWiki

Меня не устраивает НПЖ, т.к. я пока не смог получить:

• • OrphanedPages? — список документов, на которые нет ссылок,
  • WantedPages? — список документов, на которые есть ссылки, но которые ещё не созданы,

Обе эти функции удобны при создании базы знаний.

Кроме того в вики можно подписаться на отдельную страницу, в НПЖ – только стать наблюдателем в РГ. Это важный аргумент, который меня заставляет отказаться от НПЖ.

Мне нет смысла использовать какую-либо другую Вики, т.к. всё что мне хотелось бы иметь в корпоративной базе знаний поддерживается в WackoWiki? (во всяком случае насколько я знаю). Исходя из принципа простоты (я уже с этим работал, сотрудникам будет легче осваивать форматирование) и в надежде создать единую систему прав доступа (НПЖ это поддерживает) я ограничиваюсь сверху WackoWiki?.

 

#874 @ 16:08 13.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

>Мне нет смысла использовать какую-либо другую Вики, т.к. всё что мне хотелось бы иметь в корпоративной базе знаний поддерживается в WackoWiki

Есть и другие точки зрения в комментариях к management@lessi:БазаЗнанийПоУправлению

Неделя 45/2007

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

Дело №1. Стратегия. Я две недели назад думал заниматься именно ею. На прошлой неделе отвлекся на то, как её реализовывать. Во вторник – отстоял своё право сконцентрироваться именно на стратегии. В пятницу у меня был откровенный разговор с Сузирье. В субботу – набросал план статьи по перспективам развития зоорынка. Я готов вернуться к разработке стратегии. Именно в виде статьи. Карты – это следствие – наш ответ на перспективы отрасли.

Дело №2. Проекты. Корпоративные проекты стоят, во всяком случае на уровне обзоров на совете. Есть небольшой прогресс по Каталог товаров – но он слишком небольшой. Мне пока не понятна ситуация с проектами – должен ли я начинать с обзора корпоративных проектов или тех проектов, которые ждали меня и НПЖ? Это страшное слово «должен» – оно так мешает работать. Оставим решение этого вопроса «по ситуации» (вторник, среда).

Дело №3. Инструменты. В этом направлении достигнут наибольший прогресс за последние две недели.

1. Настя выкладывает в своём журнале должностные инструкции.
2. Подведены итоги работы компании в 3 квартале (приятные итоги), утверждён рекламный фонд.
3. Состоялся осенний корпоратив. Мне он явно пошёл на пользу, хотя я и не успел сделать стратегию для презентации.
4. Есть и работает site@lessi. Людей там всё прибавляется.
5. Со Светой у нас получилось сделать первую встречу по итогам недели.
6. Настя получила «добро» на понедельный график работ

Продолжая начатое:

1. Утвердить инструкцию anastasiyak@lessi:МенеджерпоПерсоналу. Позже – моя. Позже – решение вопроса по месту для публикации регламентов компании.
2. Ответить на вопросы склада
3. Задачи по релизу http://do.lessi.com.ua/public/eduardk/r11. Добавить? туда: настроить работу с DeskDo в офисе, подключить сотрудников 4 магазина к сайту, проверить публичный доступ к site@lessi, закончить site@lessi:АлгоритмРабот, анонсировать РГ в npj.ru.
4. Провести встречу по итогам недели с Настей и обсудить с ней «понедельный» график работ (разрешения на домашнюю работу или план работ на неделю)