Я внедрял в одной украинской компании AgentPlus еще когда у них клиент был для WindowsMobile. У них есть приложения для телефонов для мобильной торговли и вроде бы сейчас уже есть для курьерской службы. Приложение для мобильной торговли позволяло не только сделать заказ или отметить витрину в КПК, но и фиксировало координаты телефона в данный момент. Единственно на WinMobile определение координа безбожно тупило :( Мерчам надо было выходить на улицу и ждать 2-3 минуты, чтобы все сработало. Если интересно могу рассказать подробнее.
По машинам, там немного другое решение, на них надо ставить GPS и следить в реальном времени.
Не знаю как у Вас, у меня телефон показывает на заблокированном экране новые письма.
И вообще Вы перескочили с информационных уведомлений в системе маршрутизации торговых представителей на сообщения о критических проблемах. Сообщение от охранной сигнализации вообще током должно бить охрану\милицию пока они не разберутся :)
Есть разные уровни сообщений — одни из них критические и они должны доставлять пользователю способом, который максимально обратит на себя его внимание. В самом плохом случае, должна включаться сирена и мигалки под потолком.
Я же вел речь о том, что «всплывающие уведомления» не удобны и не нужны:
— многие не ИТ пользователи автоматически щелкают на кнопку «ОК» не читая сообщение
— у уведомления нет никаких следов, что оно пришло и что его прочитали (в отличии от той же почты или телефонного звонка)
— для получения уведомления у вас должно быть запущено приложение, для декстопа у вас должно быть активно окно программы, чтобы его увидеть, вы должны находится рядом с компьютером
— если это отдельное модальное окно, оно мешает работе
На мой взгляд, электронная почта гораздо удобнее всплывающих сообщений. Для реально важных сообщений надо использовать другие способы (звонки, сирены, ток).
Вы меня не до конца поняли. Я же не пишу, что вообще не нужны уведомления. Уведомления нужны о том, что какое-то действие надо предпринять. Я против мусорных информационных уведомлений.
Например, на зерновозах обычно стоит уведомление о простое больше 5 минут вне зоны погрузки-выгрузки. В этом случае диспетчер звонит и узнает остановили ли водителя гаишники или он зерно ворует. Если рядом есть автомобиль СБ им может прийти сообщение с координатами зерновоза и они поедут быстренько смотреть, что там происходит. На грузовиках больших стоит датчик открытия бака. Если бак открыт то система смотрит находится ли грузовик в зоне заправки. И так далее. А сообщение, что мерч зачекинился никому не надо. Так же, как и сообщение о том, что кто-то в пробке стоит, особенно в Москве :) Там этими сообщениями можно всех засыпать.
Вообще вместо уведомлений надо посылать электронную почту, а также выдать сотрудникам телефон с почтовым клиентом и обязать его носить с собой, а не оставлять на столе, чтобы весь офис слушал «Зимние розы» или «о боже какой мужчина» :)
На самом деле никому не нужны всплывающие уведомления о том, что кто-то где-то зачекинился. Само собой нужно иметь возможность построить отчет о событиях, но поверьте уведомления не нужны. Особенно если у сотрудника в подчинении 20-30 других сотрудников, он никакие уведомления читать не будет.
Вообще уведомления, на мой взгляд, должны приходить только о том, что какое-то действие надо предпринять. То есть, начальнику транспортного цеха должно прийти уведомление «Пришлите аварийку», все остальное это просто информационный мусор, который со временем мозг отфильтровывает.
Можно использовать Google Maps но в любом случае понадобится какое-то ПО. Я не уверен, что задачу коммивояжера можно решить через Google Spreadsheets.
P.S. У меня был когда-то давно проект, в котором Google Maps использовался для контроля, что сотрудник использует оптимальный маршрут, а не завышает пробег в объезд. Но там было проще, поскольку магазины были в маленьких городах\селах и обычно 1 магазин на населенный пункт.
Если для примера клиент-серверного приложения взять 1С, то мне кажется веб-приложение будет работать быстрее :)
Поддерживать проще — мы же говорим про корпоративное решение. Вполне можно корпоративно заставить всех работать в одном браузере (тот же Гугл Хром).
Опять таки плюсом веб-решения будет то, что оно работает на планшетах\мобильных телефонах, что десктоп-клиент делать уже не будет. То есть — торговый представитель может в любой момент посмотреть информацию о своем маршруте или данные о торговой точке в телефоне, сидя на совещании с планшета можно что-то посмотреть или изменить, находясь в отпуске или вечером дома, что-то можно поменять с помощью планшета.
Возможно мы с Вами говорим о разных shareholder-ах, но мой опыт говорит, что
а) никто из акционеров не будет смотреть на макропоказатели и тем более их сравнивать. Зачастую всех их интересует только P&L, Cashflow и красивая презеннтация сколько продукции произвели. Представьте себе Олега Дерипаску или Рената Ахметова, которого интересует сколько там брака было произведено на его заводе.
б) зачастую у них просто нет доступа к ERP или другим учетным системам.
Для того, чтобы это проверить и нанимают независимых аудиторов или делают свой отдел внутреннего аудита, который и должен искать это все.
Фальсифицировать отчетность в реально работающей ERP очень просто, надо фальсифицировать вводимые данные. Поверьте shareholder-ы, акционеры и владельцы не будут смотреть данные в ERP, которые приходят с конвейера, оно им не надо, их интересует только финансовая отчетность. Если речь идет о крупных компаниях с тысячами рабочих места и тысячами операций в день, то «правильная» методология руководства компании позволит показать все совсем не так, как есть на самом деле.
Ну вообще-то для того, чтобы узнать реальное положение дел в компании, нужно не ERP внедрять, а нанимать независимый аудит. Никто не мешает фальсифицировать отчеты и в ERP.
Ну ERP это ж не только планирование, это еще и учет. Зачастую в больших компаниях бывает, что учетных систем стоит несколько — бухгалтерия одна, склад другая, кадры третья, производство — четвертая + Ексель, отчеты для топов делает целый отдел (который ничем другим кроме вытаскивания цифр из разных систем не занимается).
С одной стороны все работает, все бизнес-процессы построены, но получить, для примера, себестоимость можно потратив две недели сводя циферки в Екселе.
Yggaz, Вы немного противоречите себе. Вы сначала пишете, что руководить процессом ИТ-шник не может, а потом пишите, что куратором должен быть кто-то из бизнеса. Но руководитель проекта и куратор (спонсор) проекта это две совсем разные роли. Да, они могут совмещаться, но это разные роли.
Господа, по-моему это спор ни о чем. Руководить проектом должен человек с обладающий необходимыми компетенциями. Это может быть директор по ИТ с финансовым образованием и многолетним пониманием бизнеса. С другой стороны финансовый или операционный директор завалит например кадровую часть ERP, просто потому, что не понимает ничего.
Не забывайте также о том, что у многих директоров вырабатывается особый высокоуровневый взгляд на бизнес-процессы компании. Он многие мелкие процессы которые лежат в основании (в самом низу) воспринимает как само собой разумеющиеся вещи.
По факту — есть ситуации, когда ИТ директор будет отлично рулить проектом, а любой человек из бизнеса его завалит. Хотя да, внедрение ERP это совсем не про ИТ, также как и например внедрение простой учетной системы это не только бухгалтерия.
С точки зрения бизнеса я бы еще добавил инструкции. Потому что люди меняются, одни уходят, другие приходят. Консультанты\подрядчики тоже не вечны, и со временем приходит ситуация, когда уже никто не знает\не помнит почему было сделано так и как вообще пользоваться функциями этой ERP.
Я никак не противоречу автору, я просто уточняю его (так как я понимаю).
На самом деле, в реальных компаниях, зачастую менеджеры крупных и значимых проектов, не являясь генеральным или каким-то еще директором, могут заставить\убедить\уговорить других сотрудников, даже которые им не подчиняются, даже директоров, выполнять необходимые для проекта задачи. Для этого и нужны менеджеры проектов. В теории такой тип власти может называться референтной.
У ГД, ЗГД или просто каких-то Д в реальности куча задач связанных с операционной деятельностью компании и, в реальности, они не будут полностью отдаваться проекту. Для этого есть МП, который дерет со всех три шкуры и разъясняет политику. В свою очередь с МП дерет три шкуры менеджмент компании (те самые ГД и ЗГД). ГД просто уполномачивает его в рамках проекта на все необходимые действия. То есть по большому счету, можно нанять менеджера проекта и назвать его должность «Вице-президент по внедрению ERP», но по факту так не делают (я думаю потому что ВП надо платить большую зарплату чем МП :).
Пример с кладовщиком и водителем не показывает обратное, он просто углубляет. То есть, система имеет отношение не один к одному (А поставил задачу — Б выполнил — А принял), а задача последовательна (А поставил — Б выполнил — В выполнил — А принял).
Ну а так, все остальное верно. Зачастую самые низкооплачиваеые люди могут тормозить все производство и никакие ERP не решат эту проблему. Она решается только тем, что надо дружить с головой :)
Вы немного отвлеклись от темы про внедрение ERP, на то, как и какие события должны отражаться в системе.
Ваша идея верна, но нужна идти дальше. Разберем Ваш кейс — зав.производству нужны 4 гайки. В Вашем комментарии — у данного процесса три этапа: зав.производством заказал, заказ собирают, заказ выполнен.
На самом деле все сложнее (не будем отвлекаться на то, что зав. производство обычно заказывает примерно так «Петрович, позвони Васе, пусть он 4 гайки закажет» :)) — заказ сделан, заказ собирают, заказ собран, и тут самое интересное — отгрузка со склада. То есть, кладовщик собрал и отдал заказ. С точки зрения кладовщика заказ выполнен, с точки зрения производства не выполнен, потому что гаек то у него нет. Где гайки то? А гайки они у водителя, который везет их из склада в цех (например в сельском хозяйстве расстояние может быть десятки километров по проселочным дорогам на уазике). И если он их не довезет, то это не вина кладовщика и как бы он джигу не танцевал, на водителя он не оказывает никакого влияния.
То есть, решение что результат оценивает постановщик задачи оно половинчастое, в данном случае надо отмечать в системе, когда заказ поступил, когда его отгрузили и когда он поступил к заказчику. И анализировать все это время.
Насчет оценки времени — тут тоже есть нюанс, который зовется очередью. То есть у кладовщика может быть на момент получения заказа еще 100 заказов и он их будет выполнять по очереди. Тогда к оценке надо добавлять еще параметр «Заказ принят к исполнению», а не просто оценивать сколько времени с момента получения заказа.
К тому же не следует забывать о том, что кладовщики зачастую не самые образованные и компетентные в компьютерах люди, и на то, чтобы собрать 4 гайки и 2 рессоры у него уйдет 5 минут, а чтобы их 1 пальцем набить на клавиатуре еще 20. В этом случае надо оценивать загрузку кладовщика и или садить отдельного оператора или думать в сторону DWH системы или штрихкодирования.
По машинам, там немного другое решение, на них надо ставить GPS и следить в реальном времени.
Форсквер это для хипстеров :)
И вообще Вы перескочили с информационных уведомлений в системе маршрутизации торговых представителей на сообщения о критических проблемах. Сообщение от охранной сигнализации вообще током должно бить охрану\милицию пока они не разберутся :)
Есть разные уровни сообщений — одни из них критические и они должны доставлять пользователю способом, который максимально обратит на себя его внимание. В самом плохом случае, должна включаться сирена и мигалки под потолком.
Я же вел речь о том, что «всплывающие уведомления» не удобны и не нужны:
— многие не ИТ пользователи автоматически щелкают на кнопку «ОК» не читая сообщение
— у уведомления нет никаких следов, что оно пришло и что его прочитали (в отличии от той же почты или телефонного звонка)
— для получения уведомления у вас должно быть запущено приложение, для декстопа у вас должно быть активно окно программы, чтобы его увидеть, вы должны находится рядом с компьютером
— если это отдельное модальное окно, оно мешает работе
На мой взгляд, электронная почта гораздо удобнее всплывающих сообщений. Для реально важных сообщений надо использовать другие способы (звонки, сирены, ток).
мусорныхинформационных уведомлений.Например, на зерновозах обычно стоит уведомление о простое больше 5 минут вне зоны погрузки-выгрузки. В этом случае диспетчер звонит и узнает остановили ли водителя гаишники или он зерно ворует. Если рядом есть автомобиль СБ им может прийти сообщение с координатами зерновоза и они поедут быстренько смотреть, что там происходит. На грузовиках больших стоит датчик открытия бака. Если бак открыт то система смотрит находится ли грузовик в зоне заправки. И так далее. А сообщение, что мерч зачекинился никому не надо. Так же, как и сообщение о том, что кто-то в пробке стоит, особенно в Москве :) Там этими сообщениями можно всех засыпать.
Вообще уведомления, на мой взгляд, должны приходить только о том, что какое-то действие надо предпринять. То есть, начальнику транспортного цеха должно прийти уведомление «Пришлите аварийку», все остальное это просто информационный мусор, который со временем мозг отфильтровывает.
P.S. У меня был когда-то давно проект, в котором Google Maps использовался для контроля, что сотрудник использует оптимальный маршрут, а не завышает пробег в объезд. Но там было проще, поскольку магазины были в маленьких городах\селах и обычно 1 магазин на населенный пункт.
Поддерживать проще — мы же говорим про корпоративное решение. Вполне можно корпоративно заставить всех работать в одном браузере (тот же Гугл Хром).
Опять таки плюсом веб-решения будет то, что оно работает на планшетах\мобильных телефонах, что десктоп-клиент делать уже не будет. То есть — торговый представитель может в любой момент посмотреть информацию о своем маршруте или данные о торговой точке в телефоне, сидя на совещании с планшета можно что-то посмотреть или изменить, находясь в отпуске или вечером дома, что-то можно поменять с помощью планшета.
Вот в этом и есть смысл на мой взгляд в вебе.
а) никто из акционеров не будет смотреть на макропоказатели и тем более их сравнивать. Зачастую всех их интересует только P&L, Cashflow и красивая презеннтация сколько продукции произвели. Представьте себе Олега Дерипаску или Рената Ахметова, которого интересует сколько там брака было произведено на его заводе.
б) зачастую у них просто нет доступа к ERP или другим учетным системам.
Для того, чтобы это проверить и нанимают независимых аудиторов или делают свой отдел внутреннего аудита, который и должен искать это все.
Вот классический пример http://ru.wikipedia.org/wiki/Enron, а ведь у них тоже была наверняка ERP.
С одной стороны все работает, все бизнес-процессы построены, но получить, для примера, себестоимость можно потратив две недели сводя циферки в Екселе.
Не забывайте также о том, что у многих директоров вырабатывается особый высокоуровневый взгляд на бизнес-процессы компании. Он многие мелкие процессы которые лежат в основании (в самом низу) воспринимает как само собой разумеющиеся вещи.
По факту — есть ситуации, когда ИТ директор будет отлично рулить проектом, а любой человек из бизнеса его завалит. Хотя да, внедрение ERP это совсем не про ИТ, также как и например внедрение простой учетной системы это не только бухгалтерия.
На самом деле, в реальных компаниях, зачастую менеджеры крупных и значимых проектов, не являясь генеральным или каким-то еще директором, могут заставить\убедить\уговорить других сотрудников, даже которые им не подчиняются, даже директоров, выполнять необходимые для проекта задачи. Для этого и нужны менеджеры проектов. В теории такой тип власти может называться референтной.
У ГД, ЗГД или просто каких-то Д в реальности куча задач связанных с операционной деятельностью компании и, в реальности, они не будут полностью отдаваться проекту. Для этого есть МП, который дерет со всех три шкуры и разъясняет политику. В свою очередь с МП дерет три шкуры менеджмент компании (те самые ГД и ЗГД). ГД просто уполномачивает его в рамках проекта на все необходимые действия. То есть по большому счету, можно нанять менеджера проекта и назвать его должность «Вице-президент по внедрению ERP», но по факту так не делают (я думаю потому что ВП надо платить большую зарплату чем МП :).
Ну а так, все остальное верно. Зачастую самые низкооплачиваеые люди могут тормозить все производство и никакие ERP не решат эту проблему. Она решается только тем, что надо дружить с головой :)
Ваша идея верна, но нужна идти дальше. Разберем Ваш кейс — зав.производству нужны 4 гайки. В Вашем комментарии — у данного процесса три этапа: зав.производством заказал, заказ собирают, заказ выполнен.
На самом деле все сложнее (не будем отвлекаться на то, что зав. производство обычно заказывает примерно так «Петрович, позвони Васе, пусть он 4 гайки закажет» :)) — заказ сделан, заказ собирают, заказ собран, и тут самое интересное — отгрузка со склада. То есть, кладовщик собрал и отдал заказ. С точки зрения кладовщика заказ выполнен, с точки зрения производства не выполнен, потому что гаек то у него нет. Где гайки то? А гайки они у водителя, который везет их из склада в цех (например в сельском хозяйстве расстояние может быть десятки километров по проселочным дорогам на уазике). И если он их не довезет, то это не вина кладовщика и как бы он джигу не танцевал, на водителя он не оказывает никакого влияния.
То есть, решение что результат оценивает постановщик задачи оно половинчастое, в данном случае надо отмечать в системе, когда заказ поступил, когда его отгрузили и когда он поступил к заказчику. И анализировать все это время.
Насчет оценки времени — тут тоже есть нюанс, который зовется очередью. То есть у кладовщика может быть на момент получения заказа еще 100 заказов и он их будет выполнять по очереди. Тогда к оценке надо добавлять еще параметр «Заказ принят к исполнению», а не просто оценивать сколько времени с момента получения заказа.
К тому же не следует забывать о том, что кладовщики зачастую не самые образованные и компетентные в компьютерах люди, и на то, чтобы собрать 4 гайки и 2 рессоры у него уйдет 5 минут, а чтобы их 1 пальцем набить на клавиатуре еще 20. В этом случае надо оценивать загрузку кладовщика и или садить отдельного оператора или думать в сторону DWH системы или штрихкодирования.