Отправляет email-рассылки с помощью сервиса Sendsay

Создаем свой бизнес

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Секреты бизнеса. Предприниматели рассказывают..." на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июнь 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Людмила Лунькова

Статистика

12.222 подписчиков
-21 за неделю
←   Все выпуски   →

Создаем свою информационную систему


Создаем свою информационную систему

Выпуск 17. Попытка Классификации бизнеса

 

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

С нее и начнем.

 

 

Для этого нарисуем такую таблицу.

Точкой обслуживания назовем место, где отдают деньги. Будем считать, N много больше M. Итак:

 

Количество точек

обслуживания 

Количество

Непосредственных

Исполнителей

Количество одновременных

плательщиков

Пример бизнеса

M

0

N

SMS сервис, Интернет услуги, Связь,СМИ

1

0

1

Автоматы по продаже …

1

1

N

Транспорт, Курсы, Концерты, Кинозал

1

M

N

Ресторан, Гостиница, Баня, Театр

M

M

N

Универсам, Гипермаркет

1

1

1

Торговая точка, непосредственные услуги

1

N

M

Производство – оптовики

1

N

1

Фермерские хозяйства, Консалтинг, Дизайн, Охрана, Разработка на заказ

0

N

1

Исследования

 

 

Возможно это не самая понятная классификация, но она хорошо показывает, куда в конкретном бизнесе надо направлять усилие, чтобы повысить его экономическую эффективность.  Глядя на эту табличку я смог объяснить, чем же занимаемся мы. Мы делаем нечто, что позволяет передвинуть разработку ПО от схемы 1-N-1  к схеме  1-1-1, затем к 1-0-1, а если повезет и к гораздо более эффективной схеме M-0-N, конечно для этого надо выдвинуть систему разработки приложений в Интернет.

 

Итак, что можно понять из классификации. Например, схема 1-1-1, типичный представитель – торговая точка. Ясно, что если мы можем одновременно обслуживать одного человека, то надо потратить максимальное усилие на то, чтобы как можно быстрее обслуживать конкретного покупателя. И клонировать точки обслуживания… переходя к схемам M-M-N ( универсам, гипермаркет)

 

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

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

 

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

 

Самую большую проблему составляет само описание услуги и способов ее тарификации.

Есть варианты, когда для тарификации требуется огромное количество параметров.

Тип услуги, Тариф клиента, Расстояние, Вес и т.п. , Подразделение, Город

 

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

 

Встречается ситуация, когда необходимо определить график исполнения (схема 1-N-1) , а исполнять услугу могут разные подразделения. Такая ситуация встречается сплошь и рядом. Даже в нашем производственном цикле Дизайн – Изготовление – Тестирование чаще всего делается разными подразделениями.

 

Есть ли модель, которая позволила бы нам описать бизнес такого плана?

 

Попробуем построить модель.

 

C – покупатель (клиент)

В зависимости от активности клиента (например, от объема потребляемой услуги) Клиенту может быть присвоена та, или иная схема тарификации CT

С – получает S (Услугу), которая состоит (набирается) из  услуг S1… SN, каждая услуга определяется набором параметров

P(S1)= P1.1 … P1.A

……………….

P(SN)= PN.1 … PN.Z

 

Количество параметров услуги зависит от ее типа  TS (Si)

 

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

 

ClientCost (Si)  = TRF_CLI(CT(C), TS(Si), P(Si))

SupplierCost (Si)  = TRF_SUP(TS(Si), P(Si))

 

Из общих соображений ясно, что  ClientCost (Si) > SupplierCost (Si)  , хотя это не всегда на 100% правда.  

Экономика процесса становится очевидной, все, что делается в нашей организации, от канцелярии до зарплаты директора должно оплачиваться разницей ClientCost (Si) - SupplierCost (Si).

 

Что тут можно автоматизировать всегда?  

  1. Создание первичных документов для каждой конкретной сделки
  2. Учет тарифной политики
  3. Взаимоотношения с клиентом
  4. Взаимоотношение с поставщиком
  5. Удовлетворение формальным требованиям поставщика
  6. Консолидированная отчетность
  7. Выход на бухгалтерские документы

 

Как сделать так чтобы расширение спектра оказываемых услуг ( и номенклатуры их параметров) не влияло на информационную систему и не требовало ее полной замены?

Задача достойная размышления.

 

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

 

P.S.

Еще у меня есть несколько обращений, или даже просьб.

 

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

 

Отдельно хочу обратиться к  питерским студентам, которые сейчас заканчивают учебный год. Лето хорошее время, чтобы набраться реального опыта в реализации проектов. А, поскольку подход, который мы пропагандируем в разработке программного обеспечения, немного отличается от традиционного, нам легче учить тех, кто не связан серьезным опытом.  Конечно, необходим хоть какой-то опыт работы с Microsoft Visual Studio (6.0 и выше).

 

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

 

 

Ведущий рассылки: Михаил М. Баранов
bami@realbh.ru www.realbh.ru
В избранное