О КомТех и не только...
Последние сообщения в блогах
10.11.2008 17:55:15
Аркадий Народицкий ,
Сквозь призму требований к системе
На нашем форуме
http://www.comtec.ru/feedback/forum/r...=1&TID=103
Roman Makuta упомянул продукты известнейшего западного производителя софта SAP для среднего и малого бизнеса. Недавно мне на другом форуме попалась на глаза одна тема
http://www.sql.ru/forum/actualthread....10610&pg=1
в которой некто под именем Popov19 описывал презентацию продукта SAP Business One. Хотя некоторые из этих требований, который Popov19 предъявлял к системе, могут показаться избыточными, мне показалось интересным рассмотреть их путем сопоставления с возможностями Comtec for Business.
Введу следующие градации уровня реализации:
- нет возможности реализовать
- требуется доработка ПО
- настройка силами разработчика/внедренца
- настройка администратором системы
- реализовано в состоянии поставки
Итак, требования к системе
1. Управление бизнес-процессами предприятия в рамках нескольких «своих» компаний.
Реализация: ведение единой управленческой БД с последующей автоматической репликацией (настройка силами разработчика/внедренца) данных в БД каждого юр.лица для формирования бухгалтерских отчетов.
2. Работа с клиентами.
2.1.Организация схемы Клиент – несколько юр лиц. Контроль взаиморасчетов в разрезе клиента в целом.
Реализация: (настройка администратором системы) стандартный сервис контроля взаиморасчетов на общей БД
2.2. Оценка доли прибыли предприятия и доли объема продаж предприятия за период в разрезе каждого клиента.
Реализация: (настройка администратором системы) бизнес-анализ (модуль Сбыт и снабжение)
2.3. ABC, XYZ категоризация клиентов, и настройка скидок в зависимости от категории клиента.
Реализация: (настройка администратором системы) настройка бизнес-анализа (модуль Сбыт и снабжение).
Скидки в зависимости от категории клиента реализованы в состоянии поставки (уровни цен справочника клиентов)
2.4. Просмотр всех счетов, всех отгрузок, платежей, накладных и др. документов по клиенту.
Реализовано в состоянии поставки в справке по клиенту
2.5. Закрепление менеджера за клиентом.
Реализация: (настройка администратором системы) добавлением колонки в справочник клиентов.
2.6.Регулирование доступа менеджеров к своим клиентам, счетам и другим документам.
(настройка администратором системы) в стандартном сервисе прав доступа – фильтры доступа
2.7. Учет рибейтов.(справка: рибейт – схема продаж, при которой через некоторое время покупателю возвращается часть суммы продажи (распространена в США, например, после заполнения купона и отправки его продавцу покупателю отправляется чек с некоторым % от суммы оплаты)
Реализация в зависимости от сложности схемы рибейта либо настройкой администратором системы, либо разработчика/внедренца (пользовательские сценарии)
2.8. Установка лимита дебиторской задолженности клиенту.
Реализация в зависимости от конкретного бизнес-процесса либо настройкой администратором системы (сервис условия проверки), либо разработчика/внедренца (пользовательские сценарии)
2.9. Подарки клиентам.
Реализация в зависимости от сложности условия предоставления подарка либо настройкой администратором системы, либо разработчика/внедренца (пользовательские сценарии)
3. Поставщики.
3.1. Фиксирование плановых сроков поставки по каждому поставщику и группе товаров.
Реализовано в состоянии поставки в календарном плане по каждому договору в модуле Сбыт и снабжение
3.2. Организация цепочек поставок. Заявка-заказ поставщику - счет поставщика (инвойс) - накладная.
Реализовано в состоянии поставки в модуле Сбыт и снабжение
3.3. Учет затрат на поставку и включение их в себестоимость.
Реализация: (настройка администратором системы) в приходных накладных - стандартные сервисы добавления полей, распределения суммы по колонке, перерасчета по строке.
3.4. Поставки под заказ.
Реализовано в Журнале размещения заказов и бронированием ТМЦ (модуль Сбыт и Снабжение)
3.5. Учет ГТД
Реализовано в партионном учете
3.6. Планирование платежей поставщикам.
Реализовано в Платежах по плану (модуль Сбыт и Снабжение)
3.7. Учет кредитов от поставщика.
Реализовано во взаиморасчетах с поставщиками (модуль Сбыт и Снабжение)
3.8. Планирование поставок.
Реализовано в состоянии поставки в Плане закупок и Календарном плане (модуль Сбыт и Снабжение)
3.9. Печать доверенности на получение груза.
Реализовано в состоянии поставки
4. Классификатор товаров.
4.1. Возможность организации древовидной структуры. Перенос позиций из ветки в ветку.
Реализовано в состоянии поставки. Имеется возможность ведения нескольких классификаторов.
4.2. Просмотр текущей скользящей себестоимости товара и ее истории.
Реализовано в состоянии поставки – карточка ТМЦ
4.3. Контроль и детализация логистических срезов. Находясь на товаре, я должен видеть, сколько этого товара сейчас в процесс закупки, сколько его на реализации, в ремонте и т.д., с возможностью детализации.
Реализовано в состоянии поставки – модуль Сбыт и снабжение
4.4. Ограничение доступа пользователей на просмотр себестоимости и другой информации
Реализовано в состоянии поставки – права доступа
4.5. Настройка аналогов, аксессуаров, совместимости и других взаимосвязей товарных позиций.
Работа с аналогами реализована в состоянии поставки, «аксессуары, совместимости и другие взаимосвязи товарных позиций» могут быть реализованы в процессе внедрения системы.
4.6. Хранение в базе данных изображения товара, инструкций и других файлов.
Реализовано в состоянии поставки – поля типа фото. Пользователь может самостоятельно добавить ссылки на файлы в любой справочник, документ
4.7. Формирование прайс-листа.
Реализовано в состоянии поставки – прайс-лист
4.8. Просмотр истории движения товара по складу и истории остатка.
Реализовано в состоянии поставки – отчеты
4.9. Поиск документов с этим товаром.
Реализовано в состоянии поставки – сервис справочника номенклатуры – справка о вхождении в документы
5. Редактор отчетов.
5.1. Сохранение документов в различные форматы.
Реализовано в состоянии поставки – сохранение в Excel. Может быть сохранено в PDF
5.2 Коррекция шаблонов документов из интерфейса.
Реализовано в состоянии поставки
6. Ценообразование
6.1. Средневзвешенная себестоимость и возможность ее анализа по товару. Когда было изменение, насколько и почему.
Реализовано в состоянии поставки – карточка движения ТМЦ
6.2. Формирование себестоимости товара при приходе на склад с учетом доп затрат.
Да – см. п. 3.3.
6.3. Настройка различных сценариев скидок, распродаж.
Реализация: в зависимости от сложности схемы ценообразования (настройка администратором системы в прайс-листе, либо разработчика/внедренца с использованием механизма сценариев).
6.4. Настройка для различных пользователей уровня полномочий по минимальному уровню цены на разные группы товара.
Реализация: (настройка силами разработчика/внедренца) с использованием механизма сценариев.
7. Сквозной учет товара.
7.1. Просмотр партии товара, из которой отгружен товар в данной сделке. Соответственно, FIFO себестоимость.
Реализация: в состоянии поставки путем партионного учета
7.2. Просмотр истории партии, кому отгружены остальные части партии.
Реализация: в состоянии поставки путем партионного учета
8. Первичные документы.
8.1. Нумерация счетов-фактур отдельно по каждой «нашей» фирме.
Реализация: (настройка администратором ) сервис автонумерации в зависимости от значения другой колонки
8.2. Правильное отражение ГТД в счетах-фактурах. Если товар отгружен из разных партий, разбиение строк в счете-фактуре.
Реализация: в состоянии поставки путем сервиса автоформирования документов с учетом партионности
8.3.Возможность выгрузки первичных документов в pdf, xls, doc.
В pdf-формат
9. Склад.
9.1. Учет серийных номеров изделий, история серийного номера.
Настройка силами разработчика/внедренца в партионном учете
9.2. Внесение в базу серийных номеров через сканер штрих-кода.
Реализовано стандартными сервисами
9.3. Полноценное резервирование товар на складе.
Реализовано в состоянии поставки стандартными сервисами Протокола бронирования ТМЦ
9.4. Возможность частичной отгрузки товара, частичной закупки, частичного резерва и т.д.
Реализовано в состоянии поставки стандартными сервисами
9.5.Подбор товара на складе.
Требуется доработка ПО
9.6. Учет товара на полках.
Требуется доработка ПО
9.7. Перемещение товара между складами.
Реализовано в состоянии поставки межскладскими накладными
10. Организация доступа пользователей.
10.1. Настройка функциональных ролей пользователей.
Реализовано в состоянии поставки – Администрирование – Права доступа
10.2.Возможность ограничения доступа пользователей к документам в процессе движения процесса.
10.3. Ограничение доступа кладовщиков только к «своему» складу.
Реализация: (настройка администратором системы) стандартный сервис фильтра доступа в правах пользователей
10.4.Ограничение доступа кассиров только в «своей» кассе.
Реализовано в состоянии поставки
11. Управление затратами.
11.1. Организация процесса утверждения заявки на понесение затрат.
Реализовано в модуле Бюджетирование (заявки на оплату)
11.2. Разнесение процесса понесения затрат и их оплаты.
Реализовано в модуле Бюджетирование (заявки на оплату, платежный календарь)
11.3. Квотирование затрат по подразделениям.
Реализовано в модуле Бюджетирование
12. Финансы.
12.1. Стандартные отчеты о прибылях и убытках, движении денежных средств, баланс, дебиторы, кредиторы.
Реализовано в состоянии поставки
12.2. Отдельно показатели по задолженности поставщиков перед нами, нашей перед ними и итоговой. То же самое с клиентами.
Реализовано во взаиморасчетах по договорам
12.3.Анализ значений показателей отчетности в разрезе сделок, клиентов, менеджеров, товаров, товарных групп, «наших» фирм.
Реализовано в состоянии поставки + настройка бизнес-анализа слами администратора системы
12.5.История показателей за прошедшие периоды, например история выручки за год по месяцам.
Реализация: (настройка администратором системы) бизнес –анализ
12.6.Конвертация валюты.
Реализовано в состоянии поставки
12.7.Многовалютность.
Реализовано в состоянии поставки
12.8. Банковские кредиты и овердрафты.
Требуется доработка ПО
12.9. Оформление займов у «своих» фирм.
Требуется доработка ПО
12.10. Неопознанные платежи.
Если речь идет о поступивших платежах без привязки к отгрузочным и финансовым документам, то такой отчет можно сделать силами разработчика/внедренца
12.11. Налоговые компенсации.
Требуется доработка ПО
12.12. Внереализационные доходы.
Реализовано в состоянии поставки
12.13. Открытие и закрытие «своих» компаний и расчетных счетов.
Реализовано в состоянии поставки
=========================================================================
С учетом сказанного выше наш продукт выглядит совсем неплохо и за существенно меньшие деньги. Может быть в условиях кризиса это перевесит понты от использования Западного продукта или мода на откаты сойдет на нет?
01.11.2008 10:11:42
Аркадий Народицкий ,
18 лет – все только начинается
Рожденное в муках перестройки
Далеким 30 октября 1990 года Генеральный директор НПО «Молния» Глеб Евгеньевич Лозино-Лозинский подписал Приказ о создании малого предприятия «Компьютерные Технологии». Так было положено начало нашему КомТех. Мне, тогда начальнику отдела, было не просто попасть на прием к генеральному директору предприятия – разработчика космического челнока «Буран». Но я попал в зеленую волну экономических экспериментов той поры. Меня поддержал главный инженер - Башилов А.С. и зам.директора по экономической части – Музычук В.Е.
Время было интересное – с одной стороны еще не было отчетливо понятно, что такое мощное предприятие, как Молния, уже обречено на медленное увядание 90-х, с другой стороны – хотелось понять, а чего же ты стоишь и насколько можешь быть полезным. За время многих лет работы на большом гос. предприятии было ощущение винтика в неповоротливой машине, в которой решения часто принимались не с технической стороны, а исходя «из высших интересов предприятия и министерства». На знамени конверсии тогда было организовало СП по перепродаже компьютерной техники. По тем временам, я думаю, Молния была самым оснащенным компьютерами предприятием СССР. Помимо огромного парка больших ЕС ЭВМ, на предприятии появилось около 1000 ПЭВМ на 7000 работников. Если при этом исключить рабочих цехов и начальников (первым ПЭВМ были не нужны, а для вторых – это было обязательным атрибутом), то оснащенность ИТР для конца 80-х – очень хорошая. И на вырученные деньги и по случаю очередной годовщины запуска Бурана на Молнии иногда платили премии. Один раз, помню, премию выдавали нижним бельем китайского производства, а лично мне досталось 5 пар носков. Мне повезло – носки были без дырок, а вот некоторым женщинам повезло меньше – ведь назад премию не принимали.
И вот в такое непростое время, разработав устав, я пошел к Г.Е. Лозино-Лозинскому. Несмотря на свой возраст – почти 82 года – он обладал удивительной ясностью и живостью ума. Иногда вместо лифта он несся по лестнице вверх через две ступеньки, в то время как его свита мучительно повторяла его путь с тяжелой одышкой. Так вот, Глеб Евгеньевич очень внимательно перечитал документ. Потом этот сухопарый старик проникающим взглядом посмотрел на меня и, произнеся «Ну, смотри у меня, если обманешь», подписал Устав. Наверное, он хотел добавить еще какие-нибудь напутственные слова, но передумал. О том, как он ругал своих ближайших подчиненных ходили легенды, но я, видать, рангом не вышел.
Уровень юридической грамотности тогда крайне низким, и от Молнии в Уставной фонд КомТех высочайшим повелением была внесена комната размером 28 кв.м. Предвидя возможные проблемы с таким вкладом Молнии, от имени еще троих, кто отправился со мной в самостоятельное плавание - Михаилом Ершовым, Юрием Лимановым и Юрием Мещеряковым, я также внес деньги в Уставной фонд – 3 тыс рублей (по тем деньгам – это не такая маленькая сумма). Сейчас, это звучит нелепо, но тогда для создания предприятия нужно было пройти еще и специальную комиссию при райисполкоме. Мероприятие было формальным, но запомнилось удивлением этих людей - основным занятием тех лет у создаваемых фирм была торговля и уж никак не разработка программ.
Кстати, зеленая волна скоро закончилась и, кроме нас, Молнией было организовано еще только одно МП.
Через пару месяцев, отстояв длинную очередь, мы получили свою печать.
Бухгалтер-ревизор и другие
Мы еще не начали хоз.деятельность, а уже потребовался бухгалтер. Мы взяли приходящего пенсионера – бывшего военного ревизора. Далее потребовалась печать платежек в банк. Смешно вспоминать, но программу мы сделали на основе образца бланка, который взяли в банке. Компьютер просто впечатывал данные в нужные графы. Правда, когда в банке кончились бланки и другие бланки были из другой типографии, пришлось переделывать и программу. Следующим этапом автоматизации был расчет зарплаты и кассовые документы. Ревизор приходил раз в неделю и радовался, что все на компьютере готово. Потом потребовался расчет автоматизировать ОС, и тут мы от этих ОС погорели. Перед этим был опубликован закон о поддержке малых предприятий, в котором декларировалось, что МП дано право сразу относить стоимость ОС на затраты. Естественно, мы дали почитать закон ревизору и благополучно сразу же отнесли стоимость приобретенных компьютеров на затраты. Все бы ничего, но тут налоговая по ошибке повторно и без всяких объяснений сняла с нашего р/с налог, и я не выдержал. Позвонил начальнику наловогой и, нагло полагая, что они обслуживают нас, а не мы их, вежливо попросил разобраться в их бардаке. Результат не заставил себя ждать в лице инспектора, который изучив наши бумаги, обвинил нас в недоплате налогов – мол, мало ли что в законе написано, а по бухгалтерии надо списывать затраты в течение года. На нас наложен был очень большой штраф, хотя потом через пару лет в порядке проверки района московская налоговая указала районной в этом показательном случае, что штраф должен быть еще большим. Больше начальникам налоговой я не звонил, а ревизор, потребовав прибавку за риски, тихо ушел.
Не все еще куплено
В начале 90-х нам повезло – на нас работали объективные факторы. Это и все большая доступность ПК, и бурный рост числа небольших фирм, на каждой из которых должен быть налажен учет, а также отсутствие сложившегося рынка программных продуктов и массовая переквалификация ИТР в бухгалтеры, которые начинали с нуля. С самого начала мы создали очень понятный и логичный продукт. Первоначально он предназначался для собственных нужд, потом после показа знакомым предпринимателям и на выставке дали рекламу. Хотя тот функционал несопоставим с нынешней системой, но самое главное – обучиться работать в нем можно было за пару часов. Еще в конце 91 года я случайно попал на какой-то семинар, где моим соседом случайно оказался директор одной IT-компании (теперь ее уже давно нет), который рассказал о предстоящем конкурсе программ. Мы выставили нашу систему, хотя про себя я решил, что там все уже куплено. Конкурс был двухэтапный. На первом этапе мне сказали приехать к эксперту в газету «Московский комсомолец». Оказалось, что в качестве эксперта выступал главный бухгалтер газеты. В течение нескольких часов он смотрел систему и задавал вопросы. А на втором этапе – систему смотрели уже эксперты из Финансовой академии Е.Шуремов и Дм.Чистов. Тогда это были молодые аспиранты, а сейчас они д.э.н., зав. кафедрами. Особенно помню дотошным оказался Дм.Чистов, который проводил экспертизу расчета зарплаты. Потом на итогах, неожиданно для меня, нас наградили 1 местом в классе Комплексные бух.системы для малых предприятий. Результат вдохновил нас на дальнейшее развитие системы, окончательно победив внутренние голоса о сверхприбыльности торговли шампанским, колготками и др.
Когда реклама еще работала
В то время работала любая реклама – люди еще верили печатному слову, и публикация объявления в газете мгновенно откликалась звонками из разных уголков страны. В начале 90-х годов мне удалось побывать в командировках у клиентов в Советской Гавани, Иркутске, Новосибирске, Питере, Киеве, Одессе, Ашхабаде и др. Вспоминается командировка в середине декабря в Одессу. Приехать-то приехал, а обратно билетов до января в кассах нет. Выручил директор СП, куда я приехал. Он позвонил кому-то, и мне доставили билет на самолет в Москву. Причем, по официальной цене, которая тогда составляла в пересчете на рыночный курс доллара - 50 центов.
Еще интересней была командировка в Ашхабад на комбинат строительных комбинатов. Там я столкнулся с широким азиатским гостеприимством. Каждый день в течение всей командировки примерно в 14-00 приходил директор и говорил, что слишком много работаем, пора отдохнуть. После, используя нас, как предлог (все-таки люди из Москвы приехали), очередной его заместитель вез «накрывать поляну», высказывая глубокую преданность своему начальнику. Несмотря на такие помехи в работе, систему мы установили, благодарный персонал обучили, и они еще долго ее эксплуатировали.
В самом начале 90-х был жуткий товарный дефицит и время бартера. Так за программу я как-то привез сотрудникам комплекты, состоящие из пары туфель и замшевой куртки. А в другой раз из Киева доставил тяжелую коробку с 1200 5-ти дюймовыми дискетами, хорошо, что проводили до поезда, а в Москве встретили на вокзале. А в Советсткой Гавани предложили сгонять на их рыбацком корабле в Японию. Сразу же выписали паспорт моряка и посадили на корабль. Корабль - это очень громко сказано, так что это был тот еще экстрим по штормовому Охотскому морю. Пришел в себя только через сутки уже на Хоккайдо. Правда, обратный путь мне, как "бывалому морскому волку", дался уже лучше.
На поводу принципов
С самого начала мы выработали принципы, которым стараемся не изменять:
1. Постоянно работать над совершенствованием функционала и "дружественностью" интерфейса пользователя.
2. Делать систему максимально простой для администрирования, включая автоматическое сохранение пользовательских настроек при обновлении
3. Комплексный подход к решению задач. Все модули должны быть работать с единым информационным пространством.
4. Самое внимательное отношение к задачам клиентов. До сих пор клиент, даже тот, который обслуживается у дилеров, может обратиться к нам напрямую и получить ответ. Возможность «достучаться до разработчиков» - это одно из наших конкурентных преимуществ.
Продолжение следует
26.10.2008 13:02:06
Аркадий Народицкий ,
CRM – как средство борьбы с кризисом
В условиях кризиса повышается борьба за клиентов. Требуется поддерживать их лояльность, иметь разностороннюю информацию о клиенте и его контактных лицах. Этому может помочь полноценная CRM (сокращение от англ. Customer Relationship Management — переводится как Управление взаимоотношениями с клиентами). В информационных системах, связанных с продажами, часть функций CRM в той или иной степени присутствовала всегда, поскольку даже в простейших бухгалтерских системах всегда существовала необходимость сформировать клиенту счет и зафиксировать его контактную информацию. Причем, эта функция присуща любому бизнесу, независимо от его направленности. Однако, CRM – это не только собственно продажи, это еще и организация бизнес-процессов по работе с клиентами и маркетинг с оценкой эффективности рекламных компаний, сотрудников, и ведением истории контактов. Неудивительно, что за последнее время появилось много отдельно распространяемых CRM-продуктов: MS CRM, Sales Logic, Siebel, Terrasoft CRM и др.
Однако, существенным их недостатком является необходимость интеграции с существующими на предприятии учетными системами. Это обусловлено тем, что для эффективных продаж необходима оперативная информация по взаиморасчетам, а, если речь идет об отгрузке ТМЦ, то и по остаткам ТМЦ с учетом различных факторов, например, бронирования. Нужна информация. С нашей точки зрения, построение шлюзов между различными системами – это всегда дополнительные издержки и риски потери достоверности информации либо оперативности в ее получении. В отличие от такого подхода, входящая в систему Comtec for Business задача CRM изначально интегрирована в общую базу данных, имеет с ней единый интерфейс и общие сервисы настройки.
С другой стороны, модуль CRM в Comtec for Business можно использовать как самодостаточную задачу для ведения продаж без использования других модулей системы. При этом невысокая стоимость лицензии - 10800 рублей делает модуль весьма конкурентоспособным.
Что касается первичных документов модуля, то часть из них относится к непосредственно продажам (договора с заказчиком и поставщиком, заявки от клиентов, счета, протокол бронирования ТМЦ), часть – к движению ТМЦ (накладные на приход и отпуск, межскладские), часть – к работе менеджеров (реестр контактов, индивидуальный табель, календарь событий, реестр инцидентов), часть - к маркетинговым компаниям (рассылки, маркетинговые компании). Кроме того, имеются реестры пользовательских документов, состав и содержание которых определяет сам пользователь.
В реестре контактов могут фиксироваться E-mail, контакты по телефону, личные встречи, почтовая корреспонденция. Реестры контактов, как впрочем, и любые другие документы и справочники могут включать файлы различного типа (голосовые, графические, документы Word и т.д.). Имеется возможность стыковки с почтовым клиентом и офисной АТС. Календарь позволяет планировать события и заблаговременно напоминать о них. Все документы могут содержать ссылки на аналитические справочники, используемые в системе (центр управленческого учета, изделия, шифр затрат, подразделение и др.).
Важным сервисом системы является автоформирование документов, которое по заранее настроенным шаблонам позволяет формировать из одного документа другой. В результате введение информации, например, в реестр контактов позволяет автоматически получать записи в реестре инцидентов и/или календаре.
Еще одним преимуществом системы является возможность расширения состава полей, как справочников, так и документов. Причем, воспользоваться этим сервисом может конечный пользователь без обращения к разработчикам. Кроме того, на экране можно группировать информацию по закладкам, в том числе, и пользовательским. Обработка информации и формирование документов может определяться пользовательскими сценариями – подпрограммами, запускаемыми автоматически при наступлению заранее заданных событий или нажатием кнопок на экране. В результате сочетания различных сервисов можно легко адаптировать систему к специфике бизнес-процессов.
На приведенном экране
http://www.comtec.ru//download/files/...eports.PNG
представлено меню отчетов модуля CRM, которые позволяют формировать и анализировать различные аспекты информации.
Для более глубокого бизнес-анализа запасов, трендов продаж, прогнозов доступна другая задача системы - Управление сбытом и снабжением.
20.10.2008 16:11:34
Аркадий Народицкий ,
Наши ботинки – самые лучшие, если …
Недавно один из клиентов, который начал осваивать систему после перехода с 1С на Comtec for Business, написал нам про то, как неудобно ему искать информацию. Раньше в 1С он привык для поиска в справочнике партнеров нужной организации использовать поле Краткое наименование, в котором наименование организации вводилось без ООО, ЗАО, ОАО и т.д. В Comtec такое поле не предусмотрено и «вообще, сделайте интерфейс системы по максимуму, как в 1С».
Во-первых, наша фирма является независимым разработчиком и никого копировать не собирается. В то же время мы открыты для конструктивной критики со стороны пользователей и очень ценим такую критику.
Во-вторых, если люди имели опыт работы только в одной системе, даже в такой массовой, как 1С, и рассматривают ее в качестве эталона по удобству работы, то мне это напоминает слова Жванецкого о том, что наши ботинки - самые лучшие ботинки, если других не видел.
В-третьих, дублирование информации в Полном и Кратком наименовании является примером нерационального подхода к проектированию системы.
По существу вопроса - поиск информации является существенным элементом дружественного интерфейса.
В Comtec for Business существуют различные варианты поиска:
1. Поиск по колонке (F7).
2. Поиск при помощи панели инструментов (может иметь свою настройку для каждого пользователя) см. http://www.comtec.ru//download/files/tech/f7s.flv
3. Поиск при помощи панели алфавита (при этом система игнорирует начальные ООО, ЗАО, ФГУП и т.д.).
4. Поиск путем маркировки по условию и фильтрации.
5. Поиск строки справочника из документа без входа в справочник.
6. Выбор строки справочника из документа по коду без входа в справочник.
7. Косвенный поиск путем использования системы аналогов.
8. Поиск посредством сценария работы пользователя.
В каждый конкретный момент времени пользователь может выбрать один из указанных способов. Интерфейс всех этих способов (кроме п.8) рассчитан на обычного, а не высококвалифицированного пользователя.
А сколько из этих способов знакомо Вам, уважаемый пользователь?
09.09.2008 09:32:56
Аркадий Народицкий ,
Обследование и Техзадание как необходимые условия комплексного решения
Вспоминаю, что в 90-х годах лозунгом системы КомТех – прародительницы Comtec for Business – был “Сделано для Бухгалтера”. Объясняется это тем, что решаемые задачи были ориентированы на бухгалтерский учет. При этом интерфейс был настолько простым, что позволял производить настройки обычному бухгалтеру-непрограммисту.
По мере расширения круга решаемых задач появилось управление запасами, управление договорами, бизнес-анализ, бюджетирование и др. Соответственно усложнялась и система и интерфейс настройки. И хотя некоторые настроечные операции по-прежнему могут быть выполнены непрограммистом, для эффективного и комплексного решения необходимо участие IT-специалистов. К нам часто обращаются пользователи с просьбой добавить какое-либо вычисляемое или связанное с другими таблицами поле. Решая такую локальную задачу, можно запросто получить отрицательный результат для системы. Ведь базу данных системы можно уподобить некоторому организму, в котором все органы (поля и таблицы) тесно взаимосвязаны с друг с другом. Давайте пришьем к руке еще один палец, а к нему еще один, и посмотрим, что получится. Беспорядочное добавление полей и наложение на них специальных обработок может привести к “тормозам” при обработке данных у другого потребителя информации.
Поэтому само по себе наличие системы с богатыми возможностями настройки http://www.comtec.ru/products/modules/index.php является лишь необходимой предпосылкой для построения эффективной системы. Опыт показывает, что без плотного взаимодействия поставщика ПО и заказчика, внедрение системы ограничивается решением только учетных задач. Кстати, спросите себя - на сколько процентов используются сейчас возможности системы на Вашем предприятии?
Есть ли альтернатива таким “заплатам”? Ответ: только системный подход к организации потоков информации согласно требованиям бизнес-модели предприятия. Основная проблема заключается в том, что на предприятии, как правило, отсутствуют аналитики, которые способны сформулировать комплексное решение или взять на себя ответственность за это.
Чем же можем помочь мы? Самый правильный, с нашей точки зрения, вариант включает 3 этапа:
1. Проведение обследования предприятия – включает ознакомление со структурой предприятия, его задачами, документооборотом, особенностями ведения бизнеса и др. вопросами.
2. Разработка Технического задания на доработку программного обеспечения системы. В ТЗ определяется состав решаемых задач, ответственные с двух сторон, описывается решение каждой задачи, календарный план выполнения работ и их стоимость. Техническое задание согласовывается с Заказчиком.
3. Заключение и выполнение договора на внедрение системы «под ключ» согласно ТЗ.
18.06.2008 11:00:52
Аркадий Народицкий ,
9.02 – новый интерфейс
С момента выпуска версии 9.01 прошло не так много времени – около 2-х месяцев. Однако, в целом, при благоприятном впечатлении о новом интерфейсе со стороны пользователей мы нашли способы улучшения читаемости данных и меньшей утомляемости для пользователя. С этой целью стали более отчетливо видимы разделительные границы между строками и колонками, а также был изменен оттенок маркировки на более приятный. При этом улучшилась и читаемость данных на маркированных строках.
Добавленный в версии рабочий стол системы
http://www.comtec.ru//download/files/tech/mmain.flv
позволяет создавать пользователю свое меню из тех справочников, документов и отчетов, которые используются наиболее часто. Сохранен и ранее существовавший рабочий стол для каждого модуля. Однако, преимущество рабочего стола системы заключается в том, что теперь пользователь без потерь времени на переход в другой модуль может вызвать нужный документ/отчет непосредственно из рабочего стола системы.
Естественно, мы и дальше планируем оттачивать интерфейс и функционал нашей системы.
05.06.2008 09:52:57
Аркадий Народицкий ,
Мечтать не вредно
Внедрение системы управления предприятием всегда не простой, а для некоторых работников Заказчика весьма болезненный процесс. Часто нежелание расстаться с монополией на информацию является существенным тормозом на пути внедрения системы.
Какие условия для успешного завершения проекта автоматизации предприятия среднего бизнеса?
Если помечтать и представить себе идеальную среду, то этими условиями будут:
Со стороны Заказчика:
- Высшее руководство и руководители подразделений одинаково понимают проблемы и задачи, стоящие перед предприятием. В частности, они четко представляют конкурентные преимущества компании и стремятся максимально их реализовать
- Между наемным менеджментом и собственниками нет конфликта интересов, влияющего на внедрение системы.
- Руководство научено горьким опытом предыдущего внедрения, которое, несмотря на большие инвестиции, не дало ожидаемых результатов
- Сформулированы основные требования и цели системы
- У руководства есть политическая воля для достижения результатов
- Создана команда под руководством руководителя предприятия или его заместителя для оперативного решения вопросов, связанных с внедрением системы
- На предприятии есть достаточно мотивированные IT-специалисты, которые могут и желают координировать выполнение работ со стороны Заказчика
Со стороны Исполнителя:
- проведенное обследование бизнес-процессов Заказчика выявило проблемные места, решаемые задачи и их приоритетность
- Исполнителем разработано и согласовано с Заказчиком техническое задание на проект, в котором определены этапы, решаемые задачи, способы их решения, трудозатраты и стоимость, составлен календарный план выполнения работ...
Тут мои мечты прервала суровая действительность. А жаль!
P.S. Зарегистрированные посетители сайта могут дополнить этот перечень в комментарии к блогу.
30.05.2008 10:55:05
Аркадий Народицкий ,
О недоучете и недостаче
Недавно мне задали вопрос - а как Ваша система может предотвратить ошибки в учете и недостачу товара?
Конечно, многое зависит от действующих бизнес-процессов и регламентов. Отсутствие каких-либо регламентов на предприятии - явный признак, мягко говоря, беспорядка и, как следствие, ошибок отражения реальной картины. Нормальный путь - это увязка регламентов работы с действующей информационной системой.
Следует различать неумышленное и умышленное искажение информации.
Относительно нашей системы умышленный ввод некорректной информации может быть предотвращен и/или отслежен благодаря следующим встроенным средствам:
1. Распределением прав доступа каждого пользователя вплоть до каждого поля любого справочника, документа (нет, просмотр, редактирование, редактирование только "своих" записей), до каждой функции. Можно также задать фильтр для конкретного пользователя, чтобы он мог иметь доступ к определенной части номенклатуры, складов, покупателей/поставщиков.
2. Настройкой модели истории изменений полей справочников и документов и построения отчетов, из которых видно: кто, когда и как изменял значения полей, кто и когда удалил запись.
3. Жесткой настройкой контроля остатков таким образом, чтобы нельзя было выписать отсутствующий товар. (Хотя контроль можно настроить так, чтобы система в документе при редактировании поля "количество" автоматически выводилось табло остатков по данному складу и предприятию в целом, включая остатки фактические, с учетом товара в пути, забронированного по договорам и т.д.)
4. Возможностью написания сценария работы пользователя, при котором система может проверять корректность заполнения нужных полей документа и при необходимости выводить соответствующие сообщения или осуществлять те или иные заранее запрограммированные действия (например, предотвращать формирование документов на отпуск недостающего или неоплаченного товара).
Кстати, обеспечение в системе пп.1-3 доступно обычному пользователю, не имеющих навыков программирования.
В дополнение к сказанному выше с неумышленным искажением информации в системе можно бороться:
1. Автоматизацией технологии формирования первичных документов. В частности:
- использованием технологии автоматизации оприходования, отпуска и инвентаризации товара с использованием штрих-кодирования и соответствующего оборудования по считыванию информации (сканеры, терминалы сбора данных), RFID и др.
- обменом документами с поставщиками (покупателями) в электронном формате.
2. Диагностированием благодаря разнообразным отчетам. Например, построением на любую дату отчетов, в которых система покажет, в каком документе вы ушли по товару в отрицательную зону (А если выход в зону отрицательных остатков все же допустим, то имеются и средства автоматизированной генерации соответствующих приходных документов), отчетов по отклонениям цен продажи, относительно установленных в прайс-листе , применительно к каждому менеджеру и др.
3. Работой менеджеров в реальном масштабе времени, когда система показывает корректные остатки по выбранной одновременно двумя менеджерами одной и той же позиции.
4. Построением протоколов, какие документы/проводки и из каких документов были сформированы. При этом возможно повторное формирование документов в режиме "вместо" или "дополнить".
26.05.2008 17:33:56
Аркадий Народицкий ,
Не только о футболе
Чтобы не было впечатления, что это сайт футбольных фанатов, напишу о другом. Бродя по просторам интернета, наткнулся на блог помощи для пользователей SCALA http://blog.scalahelp.ru/2007/10/erp-scala.html
« Стандартные отчеты ERP Scala
Scala в своем составе имеет большое количество отчетов. Их можно условно разделить на отчетные формы и первичные документы.
К сожалению, логика и внешний вид большинства отчетных форм зашита в коде. При большом желании их тоже можно изменить, я даже видел такое решение - сделано было на основе постпроцессора. В двух словах: в настройках канала вывода указана программа (это и есть постпроцессор), Скала формирует отчет в виде текстового файла и запускает постпроцессор, передавая ему путь к файлу. Всего-то и остается написать программу, которая будет парсить файл и делать то, что вам нужно. Еще, как вариант, можно добраться до таких отчетов с помощью VBA, но это тоже будет разборка уже готового текста. В общем - мазохизм. Если уж требуется изменить такой отчет, то я бы лучше просто попробовал повторить его в виде внешнего отчета… »
Вот как можно все закрутить в чудо-программе известного западного производителя, подумал я. Для сопоставления придется рассказать немного об интерфейсе отчетов в Comtec for Business. В отличие от SCALA и некоторых других систем, формирующих файл, который пригоден фактически только для печати или обработки какой-либо внешней системой, отчеты в нашей системе являются «живыми» . Это означает, что у нас формируется окно данных, которое может быть подвержено дальнейшей обработке стандартными средствами системы – поискам, сортировкам, маркировкам, группировкам, включая иерархические группировки и др. К сформированному отчету применимы такие стандартные средства, как автоформирование (формирование на основе данного отчета другого документа системы по заданным пользователем правилам), редактирование таблицы (добавление редактируемых и вычисляемых полей), экспорт в Excel, печать согласно настраиваемым печатным формам, графическая интерпретация и др. При необходимости из отчета можно запускать пользовательский сценарий, т.е. предварительно настроенную последовательность действий системы с программируемой логикой. Кроме того, во многих отчетах имеются кнопки, позволяющие детализировать историю формирования данных текущей строки. Например, можно не выходя из текущего отчета, сформировать отчет по первичным документам породившим данную строку. Далее можно войти в первичный документ и отредактировать его (при наличии соответствующих прав доступа) и при выходе система запросит необходимость перерасчета для редактирования исходного отчета. Таким образом, можно непосредственно из отчета корректировать первичку и получать новый отчет «без всякого мазохизма».
19.05.2008 09:32:53
Аркадий Народицкий ,
Последние из Могикан
На днях позвонил пользователь из Уфы и сказал, что очень доволен нашей DOS-версией, на которой работает. Мы же ее не поддерживаем с 2002 года! А он работает. Некоторые вещи, признался он, приходится делать вручную – например, считать больничные или отпуска. Но, в целом, он получает нужные бухгалтерские итоги.
В конце прошлого года, когда был выявлен и переведен на КомТех-8 пользователь КомТех-DOS из Старого Оскола, казалось, что, наконец, это самый последний из DOS. Как видно, мы ошибались. Вот такая вот долгая жизнь после официальной смерти. Похоже, надо устанавливать специальный приз за стойкость и лояльность самому последнему пользователю КомТех-DOS.
|
|
|
|
 |
| |
|
|
|
| Для комментариев необходимо пройти авторизацию. |
| |
 |
| |
|
