Группа 2 (Александр, Ким, Нина и Максим) от 06.12

ГЛАВНАЯ ФОРУМЫ Учебные группы Группа 2 (Александр, Ким, Нина и Максим) от 06.12

В этой теме 45 ответов, 3 участника, последнее обновление  Alexandr 2 года/лет, 8 мес. назад.

Просмотр 15 сообщений - с 1 по 15 (из 46 всего)
  • Автор
    Сообщения
  • #2406

    Alexandr
    Хранитель

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

    #2423

    Ким Фомкин
    Участник

    Кто знает бесплатные программы для создания интеллект карт?

    #2424

    Alexandr
    Хранитель

    ссылка для скачивания файла http://myfolder.ru/files/42287847 Весит метров 100
    Вот тут mindmanager с кряком… установка и использование на ваше усмотрение :)

    #2425

    Alexandr
    Хранитель

    http://powerbranding.ru/marketing_lessons/10-mind-mapping-programms/ тут еще информация про программы для карт

    #2426

    Alexandr
    Хранитель

    в составе MS Visio также есть надстройка для разработки карт…
    Но можно рисовать и так:
    в Visio

    #2429

    Alexandr
    Хранитель

    Первый вариант структуры процессов от Кима
    Жду ваших предложений, вопросов, комментариев и т.д.

    #2430

    Alexandr
    Хранитель

    Ким, хорошая работа.
    Несколько моментов по схеме:
    1) Что есть процесс взаимодействия обеспечивающими подразделениями?
    2) ПО поводу вопроса о том, нужно ли во входы и выходы включать отчетность и прочий документооборот. Конечно, нужно. Это же такие же полноправные информационные входы и выходы как и другие. А входы/выходы планов, без соответствующих входов/выходов отчетности — вообще превращаются в планы ради планов.
    3) Я бы рекомендовал несколько аккуратнее обращаться с базами данными — все-таки это хоть и довольно широкий термин, но все же не бесконечно. 1С, база данных заказов и т.д. — это бесспорно базы данных, а вот «БД Программ для подбора запчастей» или «Программа по ценообразованию и выбору наивыгоднейших вариантов» — это скорее ресурс, т.е. вспомогательное ПО, ведь они не преобразуются в ходе выполнения процесса. И «Книга кассира», «Планы компании» и тем более касса — все-таки немного не база данных, это отдельные полноправные входы/выходы. Вот когда данные из книги кассира попадают в учетную программу (туже 1С), то эта программа выполняет роль базы данных. И эти данные могут быть доступны другим процессам.
    4) Очень полезная вещь для построения структуры процессов — это привязка входов и выходов. Т.е. указать (можно прямо в этой таблице), кто (процесс, клиент, поставщик и т.д.) поставляет или получает вход или выход. Без такой связи не совсем очевидно взаимодействие процессов и их последовательность.
    5) Процесс «Планировать работу» — очень важно корректно называть процессы, в данном случае не совсем очевидно процесс планирования работы чего имеется ввиду: магазина, компании, отдела продажи т.д.
    6) У процесса «Управление розничным магазином» есть вход «Обращения клиентов», это что-то принципиально отличное от заявок клиентов в процессе «Обработка обращений»?
    7) Выходы «Получены деньги и выдан товар клиенту» или «Оформлены и выданы возвраты поставщикам» и другие с глаголами в прошедшем времени — не совсем корректны. В такой форме — это завершающие события, а не выходы. А выходы это, например, «Денежные средства» у кассира, «Товар» у клиента, «Накладные документы на возвратный груз» у поставщика и в бухгалтерии, «Возвратный товар» у поставщика и т.д.
    8) Я бы рекомендовал все-таки выделить процессы по типам, что бы было видно какие процессы здесь основные, какие управляющие, какие вспомогательные, и заодно хотя бы зарезервировал, т.е. просто отобразил бы на схеме без входов и выходов, другие процессы компании: «управлять персоналом», «Осуществлять маркетинговые мероприятия» и т.д.

    #2431

    Ким Фомкин
    Участник

    1) Тут имеется в виду взаимодействие Руководителя магазина с Руководителями других подразделений. Допустим программа 1С перестала работать и Руководителю магазина, необходимо оперативно позвонить Руководителю (сотруднику) IT отдела, т.е. необходимы процедуры взаимодействия… Или проводим акцию -20% на фильтра, клиенты начали звонить в магазин, возникли вопросы: необходимо ли к -20% добавлять индивидуальные скидки… Суть понятна по Взаимодействию с подразделениями (Решение операционных/нестандартных вопросов)

    #2432

    Alexandr
    Хранитель

    Суть понятна по Взаимодействию с подразделениями (Решение операционных/нестандартных вопросов)

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

    #2433

    Ким Фомкин
    Участник

    Если в 1с и Обращения и Заказы и Клиенты, в БД писать разные названия или просто 1С??

    #2434

    Alexandr
    Хранитель

    Если в 1с и Обращения и Заказы и Клиенты, в БД писать разные названия или просто 1С??

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

    #2437

    Alexandr
    Хранитель

    Стало еще лучше:
    Второй вариант схемы от Кима
    Ким обещал и дальше развить схему.
    Кстати, нет ничего удивительного или неправильного в том, что первые варианты еще многократно корректируются и дополняются. Иногда на разработку только схемы процессов для крупной компании может уходить до года.
    По вопросам (выделено на схеме красным):
    1) на вопрос про 1с ответил выше
    2) В какой момент идет контроль фактической выдачи заказа: в Управленч или на уровне выдачи? (клиент 2 дня не приходит). Честно говоря, пока я не могу разобрать в чем разница в этих двух процессах на уровне обработки заказов, как они связаны между собой и т.д. О чем и спрашивал выше. То есть мне не очевидно какая именно работа по обработке заказов клиентов выполняется в процессе Управления магазином. Поэтому касательно именно этой схемы — ничего конкретного не скажу. Но могу описать как это происходит чаще на практике. Все что касается обработки заказов клиентов — выносится от отдельные процессы. Там может быть отдельный подпроцесс, в ходе которого будет осуществляться анализ и планирование обработки заказов, но это будет именно управляющий процесс для работы с заказами клиентов. А в процессе управления магазином (или любой другой компанией) остаются именно общие управленческие функции: планирование, анализ и оценка деятельности, разработка стандартов (в зависимости от масштабов предприятия ее могут выносить в отдельный процесс), и т.д.
    3) Если клиент принес возврат, нужно оформить как новый процесс или включить в процесс выдачи заказов??? Опять же не вижу связи между процессами, поэтому однозначно не скажу. Многое зависит от документа оборота и работы ПО. Чаще процесс возврата является отдельным процессом, иногда ветвлением процесса поступления товара (это ведь формально поступления товара, но немного с другими документами), но можно и построить как подпроцесс процесса выдачи заказов. При последнем варианте немного начнется путаница во входах и выходах, т.е. на вход процесса выдачи начнут поступать входящие потоки, что затрудняет понимание процесса.
    4) В случае, когда поставщик что либо не довез или позвонил, что заказанного товара не оказалось на складе??? Обработка этого исключения вполне логична в этом же процессе. А вот как осуществлять уже — зависит от конкретной специфики. Я лично не любитель таких зависших случаев, т.к. они сбивают учет. Поэтому на недовоз предпочитал сразу оформлять акт недостачи. Если же он позвонил и сказал, что сегодня нет, то красивым вариантом будет досрочно прервать данный подпроцесс и повторно отправить заявку на поиск запчастей в предыдущий (Оформление заказа). Кстати, возможно стоит смести акцент с оформления заказа именно на поиск поставщика, вначале ведь происходит поиск, а только потом оформление.
    5) Если спортный вопрос и товар может не соответствовать Условиям (например уже был установлен и поставщик назад не примет), но мы пробуем вернуть поставщику, при этом $ пока клиенту не выдаем? Опять же как именно это осуществлять лучше именно в данной компании — не скажу, потому что не вижу, и вообще как лучше — гораздо лучше известно самим работникам компании. Возможно, стоит принимать их с каким-нибудь отдельным статусом в системе, чтобы они не были доступны к продажам и можно было контролировать процесс. Но представляется, что осуществлять эту деятельность лучше именно в этом процессе.
    6) Данную процедуру проводит менеджер, который оформляет заказы у поставщиков, может включить данный процесс к процессу Обеспечение запчастями клиентов? У какого-либо работника может быть очень много ролей в самых разных процессах. Если пытаться строить схему деятельности от работников и подразделений — это будет уже не процессный, а функциональный подход. Поэтому в текущем варианте возвраты, выделенные в отдельный процесс, представляется более красивым решением, с отдельным поток материалов и документов, с отдельным контуром контроля.

    #2438

    Тест :)
    Test 2

    #2440

    Тест 3

    #2441

    Ким Фомкин
    Участник

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

Просмотр 15 сообщений - с 1 по 15 (из 46 всего)

Для ответа в этой теме необходимо авторизоваться.