zenkov_ae

Добрый день!

Хочу поделиться своими ощущениями после посещения конференции, организованной FinPro, прошедшей в Хельсинки. Конференция была организована для финских компаний, желающих инвестировать в российские интернет проекты такие как социальные сети, медиа, игры и т.п. Наш интернет был представлен собственно российским отделением FinPro, а также, как было сказано в преамбуле, “lovely Russian girls” из Одноклассников и Яндекса. Также были мы .

Какие выводы я сделал для себя по результатам конференции:

1. Финнам ОЧЕНЬ интересен российский интернет рынок. И это легко объяснимо. Он пятый по объему в мире, уступая лишь США, Китаю, Японии и Германии. У нас большое количество пользователей и время, проводимое ими в интернете значительно больше, чем в других странах. Также есть интересный национальный фактор: западные интернет гиганты у нас не имеют привычных первых мест ни по количеству пользователей, ни по денежному доходу. Например, поисковик № 1 в России – Яндекс, социальная сеть №1 – Вконтакте (а Facebook лишь третий) и т.п. практически во всех сегментах рынка.

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

3. При реализации совместных проектов ориентированных на Россию, есть потенциальная возможность вывода решений NSG Soft на западные рынки, в первую очередь, на рынок Финляндии.

4. Немного шуточный, но поучительный вывод. Девушки из Одноклассников должны были во время своей презентации сказать, что они №1 в России. Мне было интересно, как они это сделают, ведь по количеству пользователей у нас лидирует сеть ВКонтакте. Предложенный вариант мне очень понравился: «ВКонтакте является более технологичной сетью, за счет чего привлекает к себе молодёжь. Если же сравнить платежеспособный контингент, то Одноклассники №1 в России». Аплодисменты. 

Помимо этого, хочу сказать пару слов в защиту (никогда не думал, что буду их защищать, но справедливость требует  ) городских властей Петербурга. Хельсинки в этом году удивил наличием большого числа плохо убранных от снега улиц. Конечно, все магистрали и основные центральные улицы вылизаны по-фински до асфальта, но стоит уйти в сторону и видим знакомую картину – закопанные в снегу автомобили, пропадающий в сугробах правый ряд и т.д. Нет, конечно, с тротуарами в Хельсинки все в порядке – они почищены, ходить в отличие от Питера, удобно и безопасно, но всё-таки видно, что снега этой зимой выпало действительно много.

 Сегодня мне прислали ссылку на статью с громким названием "Новая среда разработки для .NET - Прометей". Немало в сети подобных проектов. Каждый имеет свои достоинства и недостатки. Я ничего не имею против конкретно этого проекта, но хочу высказать мысли по поводу подхода к созданию подобных систем. Прошу учесть, что все что я буду писать верно именно для эффективного построения бизнес-приложений, а не приложений вообще.

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

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

3. Расширенный синтаксис SQL без "лишних JOIN" -  тоже правильная идея. Например, такая запись SELECT Заказ.Покупатель.ИНН должна приводить автоматическому вызову JOIN таблицы покупателей. Однако, надо набраться смелости и пойти еще дальше. Я понимаю, какой объем помоев на меня выльется после этой фразы, но... надо убрать SQL из написания кода ВООБЩЕ. ну, может быть, оставив его для особо сложных случаев. SQL запросы должны генерироваться платформой по написанному коду. Этим мы решаем сразу множество вопросов:
- резко понижаем требования к квалификации разработчиков (а это очень важно, т.к. мало людей хорошо разбирающихся в бизнес-процессах и SQL одновременно)
- Увеличиваем скорость написания кода и его понятность, т.к. многие SQL запросы на несколько страниц можно записать коротко
- Легко отлаживать и вносить изменения на лету
- Контроль ошибок на этапе компиляции, а не на этапе исполнения (это ОЧЕНЬ важно, в том числе, если вы получаете новую версию базового продукта и вам нужно скомпилировать ваш измененный продукт на его основе).

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

Помимо этого, любая успешная бизнес платформа должна обладать готовыми полнофункциональными решениями. Вести каждую разработку с нуля - непозволительная роскошь в наше время.

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

Нет, я не про то, что электронные таблицы (для краткости, буду именовать их Excel, хотя это не обязательно продукт от Microsoft) не нужно использовать, что они плохие  и т.п. Конечно, нет. Использовать их нужно, и они очень удобны, но надо понимать их ограничения. Был однажды такой забавный случай, когда секретарша (очень милая девушка) в одной из фирм, находящейся у нас на сопровождении (а было и такое J) прибегает в панике и говорит: «Саша! У меня Excel делает математические ошибки!». Это тоже ограничение: не умеете – не используйте. Но я, конечно же, хочу рассказать об использовании Excel в учете.

Многие ли компании используют Excel в своей работе? Наверное, практически все. В разной степени и разными целями. Когда сотрудники начинают его использовать? Когда ПО используемое в организации не может решить тех или иных задач. Довольно часто его используют для решения задач управленческого учета, например, ведут учет движения денежных средств, взаиморасчетов, затрат, зарплаты и т.п. Вроде бы удобно, можно придать информации любую форму, не надо обращаться за доработкой существующего или разработкой нового ПО, но есть и подводные камни.

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

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

Можно вспомнить еще кучу минусов, ограничение по количеству записей, практически невозможность совместной работы и т.п. Но и первых двух минусов вполне достаточно. Самое печальное, что люди, ведущие такого рода учет полностью уверены, что делают все правильно. Переубедить их крайне тяжело, только указывая на ряд ошибок. У нас был пример одной такой фирмы, где взаиморасчёты (пусть и довольно сложные) велись в Excel. Их можно было убедить подписать практически любой акт сверки, т.к. по их данным одна и та же компания (или человек) могли проходить под несколькими названиями, например, «Ромашка», «ООО Ромашка», «Иванов» (по фамилии директора) и т.д. свести воедино весь массив было практически невозможно.

Так что мой совет – используйте Excel по назначению, а для целей учета – используйте специализированное ПО. Желательно, настраиваемое, чтобы не было желания часть работы все-таки делать в Excel. Наш Bon Commerce для этого вполне подойдет. Я, например, его использую даже для ведения домашней бухгалтерии.

Большинство клиентов, которые «вдруг» решают заняться автоматизацией учета на новом уровне начинают заниматься этим не от хорошей жизни. Вроде бы и бизнес то же, и по бух. Отчетности все хорошо, но вот денег почему-то нет. В чем причина? Как ее найти и как исправить? Не поздно ли уже?

Наши решения направлены на постановку именно управленческого учета, в то время как большинство идет от бухгалтерского. А это действительно разные вещи. Можно привести множество примеров, но давайте начнем с задач. Управленческий учет направлен на получение максимально объективной и детализированной картины всех бизнес-процессов, происходящих на предприятии в то время как задача бухгалтера – правильно учесть все операции с точки зрения правильного начисления налоговой базы. При этом бух. Учет можно вести укрупнено, не искажая при этом конечный результат. Приведу пример из нашей практики. Автоматизируем учет на консервный заводе по выпуске шпрот и кильки. Для тех, кто не знает, шпроты – та же килька, только определенных размеров (не слишком большая и не слишком маленькая) и проходящая дополнительную термообработку в печи. Таким образом, выпуская шпроты, производят сортировку исходного сырья (кильки) и пригодную часть отправляют на изготовление шпрот, оставшуюся (ну не выбрасывать же) на изготовление другой продукции, например, кильки в томатном соусе. Стоит задача правильного расчета себестоимости продукции. Бухгалтерия честно умножает стоимость исходного сырья на количество кильки в банке плюс сопутствующие материалы, получает стоимость шпрот и кильки. Результат получается довольно странный: рентабельность шпрот зашкаливает, а кильку получается невыгодно производить. Очевидная чушь, килька-то нам достается практически бесплатно – мы же делаем ее из отходов. Однако с точки зрения налогового учета – все в полном порядке. В данном случае, ошибка была очевидна, т.к. себестоимость кильки получалась выше продажной стоимости, а если бы она была завышена только на 20%? Никто бы и не заметил.

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

 Поздравляю всех с Новым Годом!
До встречи в новом году, пусть он будет лучше всех предыдущих!

Алексей Зенков.

 

Этим постом я хочу открыть целую серию, посвященную объяснению того, чем занимается компания NSG Soft и я, являясь ее руководителем. Начну с ответа на вопрос: «Зачем все это?».

Действительно, на рынке существует огромное количество самых разнообразных программных продуктов, предназначенные для автоматизации учета в различных сферах деятельности. Зачем нужен еще один? На кого он ориентирован?

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

1. Продукт должен быть универсальным. У универсальных продуктов есть огромное преимущество – большой рынок, как минимум, на пару порядков превосходящий  по числу потенциальных клиентов рынок специализированных решений. Таким образом, только универсальный продукт может быть сравнительно недорогим. А это условие является крайне важным для конечного потребителя в сегменте СМБ, конечно при условии, что функционал при этом не страдает. 

2. Программный продукт должен быть адаптируемым (настраиваемым). В данном пункте я имею в виду то, что никто не может объять необъятное (если верить Козьме Пруткову), поэтому, если предлагаемое решение не будет настраиваемым, то мы сильно сужаем себе рынок, либо заставляем организации перестраивать свои уникальные бизнес-процессы под наш взгляд.  В рекламе одного из производителей софта (не буду приводить названия и фамилии, чтобы никого не обидеть) делается акцент на то, что клиентам нравится закрытость системы (т.е. невозможность ее донастройки, адаптации). Цитата: «Относительно преимуществ, для нас основное – это надежность платформы и закрытый код продуктов… Если раньше, чтобы максимально удовлетворить клиента приходилось круглые сутки дорабатывать системы с открытым кодом, то с «Название продукта», я в шесть часов всегда дома, т.к. если клиенту что-то надо дополнительно, этим занимается Производитель ПО.» Почему я привел этот пример? Здесь наглядно показано лукавство производителя. Ведь исходя из того, что продукт является открытым совершенно не следует то, что он не удовлетворяет пользователя и всегда требует доработки, а также то, что фирма-производитель не предоставляет  платной или бесплатной услуги по введению новых опций в базовый продукт. Например, у нас, есть и то и другое. И есть множество типовых внедрений, при которых НИКАКОЙ доработки не производилось. А вот возможность этого никак нельзя назвать минусом, тем более, если многое можно сделать своими силами (уверен, что к тому же не бесплатно). Поэтому, решение должно быть настраиваемым. 

3. Решение должно быть платформенным. Что такое Платформа и что она дает? Платформа – это набор компонент, которые предоставляют разработчику БЫСТРО, КАЧЕСТВЕННО, единообразно, не обладая глубочайшими познаниями в области программирования создать программный продукт или модифицировать существующий. Безусловно, можно написать любую программу «с нуля». Иногда, даже можно получить положительный результат на выходе, но чаще всего, сказка заканчивается, когда увеличивается нагрузка на базу, объем этой самой базы данных или число пользователей. Тяжело предусмотреть все подводные камни с которыми предстоит встретиться, а с учетом развития компании заказчика, могут появляться новые задачи. Модификация программы становится все более трудоемкой, код запутанней, компания начинает зависеть от одного человека – программиста, написавшего программу и т.д. Тут на выручку и приходит Платформа. Она берет на себя всю черновую работу за программиста, часть задач становится возможным решить вообще без программирования, результат достигается быстро с написанием минимального количества строк кода, в стандартизированном виде. 

4. Платформа должна предоставлять механизмы поддержки созданных партнерами и пользователями собственных решений на ее основе. В процессе работы Партнеров возникает большой набор внедренных решений, адаптированных своими силами под различные сферы деятельности. Например, на основе базового программного продукта (в нашем случае Bon Commerce) вы создали решение для автосервиса, службы доставки, розничного магазина и мясокомбината. В каждом случае вам пришлось что-то добавлять в конфигурацию, что-то скрывать в ней. Что делать дальше? Базовый продукт продолжает свое развитие, получает новые возможности, а ваши решения остались на том уровне, на котором вы их начали делать? Именно так и будет, если Платформа не предоставит возможности совмещения сделанных изменений (например, 1С) или механизма наследования конфигураций (наша NSG Soft Framework). В этом случае, становится возможно поддержание своих конфигураций в актуальном относительно базовой версии состоянии. Причем наш подход намного лучше. Он позволяет вам не копировать наш код, а только дописывать или заменять те куски его, которые не удовлетворяют клиента. Это делает поддержание целого набора конечных конфигураций делом максимально простым, что резко сокращает ваши трудозатраты. 

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

Уже только эти критерии (а список далеко не полон) позволяют сделать вывод, что, по крайней мере, для рынка СМБ существуют только два продукта, удовлетворяющих всем этим критериям. Наш (Bon Commerce, Bon Appetit) и продукты компании 1С. Более детальное сравнение я проведу в следующих постах.

Разрешите представиться. Я - Алексей Зенков, ген. директор компании NSG Soft, доцент кафедры БЖД Санкт-Петербургского Государственного Электротехнического Университета (ЛЭТИ).

Этой записью я открываю свой блог. Всем привет!