Автор |
Тема: "W ON" - как ошибка (Прочитано 2716 раз) |
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
on 21.02.06 в 11:18:38, IBZ wrote: Полностью подписываюсь под каждым словом. Программа должна "разговаривать" на языке конечного пользователя - бухгалтера, а не "прослойки" - разработчика приложений. |
| И я тоже полностью подписываюсь под каждым словом. При этом акцентирую внимание: ФБП - прослойка разработчика приложений, а программа учета - результат деятельности разработчика приложения. Не так ли? P.S. Исправил определение.
|
| « Изменён в : 21.02.06 в 15:04:02 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением, Александр.
|
|
|
IBZ
 

Просмотреть Профиль | E-мэйл
Сообщений: 68
|
on 21.02.06 в 11:56:11, Alexander, Kiev wrote: И я тоже полностью подписываюсь под каждым словом. При этом акцентирую внимание: ФБП - прослойка разработчика приложений, а программа учета - результат деятельности разработчика. Не так ли? |
| Немного не "въехал" в смысл последней фразы. Вообще-то схема такая: ФБП от HD - разработчик приложений - конечный пользователь. В принципе среднее звено, на мой взгляд, лишнее. Но это данность, установленная HD. Так вот, последнему звену глубоко плевать на длину предшествующей цепочки. Конечный пользователь хочет одного - иметь понятную ему программу, полностью перекрывающую его нужды. И если мы хотим работать для бухгалтера, менеджера, финдиректора и т.д., то вопрос языка общения является, возможно, более важным, чем, например, функции работы с массивами э/параметров. Я, во всяком случае, всегда очень внимательно относился к замечаниям такого рода. С уважением, Игорь.
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
on 21.02.06 в 13:14:59, IBZ wrote: В принципе среднее звено, на мой взгляд, лишнее. |
| А зачем мы тогда все нужны? on 21.02.06 в 13:14:59, IBZ wrote: ...Так вот, последнему звену глубоко плевать на длину предшествующей цепочки. Конечный пользователь хочет одного - иметь понятную ему программу, полностью перекрывающую его нужды. |
| Ну конечно же. Поэтому чем сложней и специфичнее конечное приложение для пользователя тем длинее цепочка. Возьмите 1С: Разработчик платформы - разработчик приложения - внедренец приложения - сопровождение приложения - конечный пользователь. Третий и четвертый уровень как правило совмещены. Но общее три по самому минимуму, а четыре - типичная практика.
|
| « Изменён в : 21.02.06 в 14:01:01 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением, Александр.
|
|
|
IBZ
 

Просмотреть Профиль | E-мэйл
Сообщений: 68
|
on 21.02.06 в 13:59:36, Alexander, Kiev wrote: А зачем мы тогда все нужны? Ну конечно же. Поэтому чем сложней и специфичнее конечное приложение для пользователя тем длинее цепочка. Возьмите 1С: Разработчик платформы - разработчик приложения - внедренец приложения - сопровождение приложения - конечный пользователь. Третий и четвертый уровень как правило совмещены. Но общее три по самому минимуму, а четыре - типичная практика. |
| Да не нужны мы по большему счету . Ну не то, чтобы уж совсем. Нужны в качестве конкурента, подстегивающего производителя конечного продукта, готового к немедленной работе. И сим производителем мне видится HD. Тут 1С, мне кажется, на 100% права. Есть типовая настройка от производителя и есть инструмент. Хочешь пользуйся готовым, а хочешь перепиши все с нуля под себя или на продажу. А 4-5 уровней есть размазывание ответственности. "Я пуговицы пришивал, к пуговицам претензии есть??". Впрочем, тут я вторгаюсь в чужую область, а посему умолкаю. С уважением, Игорь. P.S. Строительный софт продается напрямую или с одним чисто торговым посредником. Вся ответственность в полной мере лежит на производителе. P.P.S. А вот интересно какая цепочка экономического ПО у буржуев в буржуандии.
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
Боюсь Игорь, Вы заблуждаетесь относительно типовой настройки от 1С. Типовые настройки шлепают т.н "франчайзи". Изначально у них была таковая. Я только по Украине знаю трех мощных производителей приложений и сами они внедрениями не занимаются. Тут дело не в разбазаривании ответственности, а в распределении этапов создания конечного продукта основываясь на разных уровнях универсальности. Невозможно объять необъятное. т.н программисты 1С с очень большой натяжкой могут называться программерами. В тоже время их много, а взрослых программеров создающих приложения с нуля мало и у них серъезная квалификация. Радуйтесь нише, предоставленной нам от HD
|
| « Изменён в : 21.02.06 в 17:01:26 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением, Александр.
|
|
|
Arkady
Administrator
    

Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
on 21.02.06 в 15:00:46, IBZ wrote: Да не нужны мы по большему счету . Ну не то, чтобы уж совсем. Нужны в качестве конкурента, подстегивающего производителя конечного продукта, готового к немедленной работе. И сим производителем мне видится HD. ... |
| А я всегда "говорил и говорю"(c), что это из области нереального - конечный продукт для автоматизации учета, подходящий всем и каждому. Я очень доволен, что мы с самого начала заняли здесь правильную для маленького предприятия нишу - производство платформы. И я просто счастлив, что мы избегаем "шитья на заказ" И разделение труда, Игорь, всегда было и будет. Кто-то пишет компиляторы, а кто-то использует эти компиляторы для написания своих программ.
|
|
Зарегистрирован |
|
|
|
IBZ
 

Просмотреть Профиль | E-мэйл
Сообщений: 68
|
on 21.02.06 в 15:42:25, Arkady wrote: А я всегда "говорил и говорю"(c), что это из области нереального - конечный продукт для автоматизации учета, подходящий всем и каждому. Я очень доволен, что мы с самого начала заняли здесь правильную для маленького предприятия нишу - производство платформы. И я просто счастлив, что мы избегаем "шитья на заказ" И разделение труда, Игорь, всегда было и будет. Кто-то пишет компиляторы, а кто-то использует эти компиляторы для написания своих программ. |
| Не факт. Если проводить аналогии с шитьем, то скажу. что абсолютное большинство людей идут в гости в костюмах, сшитых на фабриках, а не на заказ. Уже молчу о прочей одежде. Как-то попробовал подсчитать сколько всего типовых операций возможно по основным средствам. И что-же - получилось несколько десятков, ну пусть сотня. " И это все ребята !" Конечно, производство посложней будет. Особенно если писать оперативный учет. Но и оно конечно. А все что конечно и алгоритмизируемо .... Кроме того ФБП обладает уникальной возможностью, отсекая все лишнее, очень быстро добираться до нужной операции. Александр, правда, называет такие настройки "монстроподобными" И вообще, "когда задача легкая - ее отдают индусам, когда сложная - китайцам, а когда неразрешимая - нашим" Впрочем, я об всем этом уже неоднократно говорил. Что же до разделения труда ... Сейчас мой друг второй год строит дом. Вместо того, чтобы нанять главного строителя-распорядителя (достаточно распространенный вид деятельностью) он находит какие-то дикие бригады, выполняющие отдельные куски. Это тихий ужас, причем все вновь пришедшие обвиняют предыдущих НИКОГДА НЕ ДЕЛАЙТЕ ТАК С уважением, Игорь.
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
Ну вот Игорь, Вы себе и противоречите. Использование готового шитья говорит о большем количестве различных производителей способных удовлетворить разнообразный спрос. Вы ведь призываете заниматься пошивом производителя материи. Не так ли? Что касается Вашего товарища, то он просто переоценил свои возможности. Умение управлять другими и учитывать дано очень не многим. Каждый должен заниматься тем, что у него хорошо получается. Как и тот факт что сейчас много бухгалтеров и программистов, а хороших и тех и других большой дифицит. В свое время (как же, помню ) я назвал реализацию методами количественного беспредела монстроподобием. Можно в одной единственной форме ввода операций, с 3-5 опциями, формализовать все 100 листьев операций с о.с. Верите? А каково оператору выбрать нужное ветвление из ста возможных конечных вариантов. Ветки конечно дают возможность преселекции, но при таком объеме, и ограниченном размере самих преселекторов это уже довольно проблематично. Для уверенности в своих действиях ему (оператору) нужно ориентироваться в составе листьев. Последнее уже граничит с конкуренцией ручными проводками. Самая что ни на есть универсальность. Моя наверное фарта, что уловил в свое время. ФБП не бухгалтерская программа, а СУБД, ориентированная на учетные потребности, с действительно уникальными возможностями, таковой ее и воспринимаю по сей день
|
| « Изменён в : 21.02.06 в 18:34:26 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением, Александр.
|
|
|
Vladimir
   
 Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 267
|
on 21.02.06 в 15:00:46, IBZ wrote: P.P.S. А вот интересно какая цепочка экономического ПО у буржуев в буржуандии. |
| Докладываю про буржуандию. Продукт для малых и средних предприятий QuickBooks www.quickbooks.ca продается как есть, никаких настроек нет вообще. Проводки вносятся в ручную. Чтобы создать одну проводку надо сделать 2 записи - одну по дебету, другую по кредиту. Занимает примерно 90% рынка. Продается либо непосредственно с сайта либо в магазине. Имеется некоторое количество услуг по ее установке и обучению, но это уж совсем для тупых пользователей. Я сам ею пользуюсь для подготовки финансовых отчетеов. Однако для оперативного учета использую ФБП. Ну как на QuickBooks сделаешь грфик отгрузок, комплектацию товара с одновременной генерацией заказа и счета на оплату, отслеживание истории продаж и тд. и тп. Одно меня печалит. Ну тесно мне в рамках одного года. Бухучет - непрерывный процесс. А ФБП рубит его на года. А мой год не совпадает с календарным.
|
|
Зарегистрирован |
С уважением, Владимир
|
|
|
Aleksey
  
 Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 133
|
on 21.02.06 в 19:42:53, Vladimir wrote: Одно меня печалит. Ну тесно мне в рамках одного года. Бухучет - непрерывный процесс. А ФБП рубит его на года. А мой год не совпадает с календарным. |
| Горячо поддерживаю! Если Финансы выросли из бухгалтерской программы в платформу для систем учета и управления, то необходимо раздвинуть рамки одного года.
|
|
Зарегистрирован |
|
|
|
IBZ
 

Просмотреть Профиль | E-мэйл
Сообщений: 68
|
on 21.02.06 в 17:31:18, Alexander, Kiev wrote:Ну вот Игорь, Вы себе и противоречите. Использование готового шитья говорит о большем количестве различных производителей способных удовлетворить разнообразный спрос. Вы ведь призываете заниматься пошивом производителя материи. Не так ли? Можно в одной единственной форме ввода операций, с 3-5 опциями, формализовать все 100 листьев операций с о.с. Верите? А каково оператору выбрать нужное ветвление из ста возможных конечных вариантов. Ветки конечно дают возможность преселекции, но при таком объеме, и ограниченном размере самих преселекторов это уже довольно проблематично. Для уверенности в своих действиях ему (оператору) нужно ориентироваться в составе листьев. Последнее уже граничит с конкуренцией ручными проводками. Самая что ни на есть универсальность. |
| Не вижу противоречия. То о чем Вы говорите - обычная конкуренция производителей. Шить производителей не предлагаю, а считаю, что на выходе фирмы, занимающейся любыми прикладными задачами должен быть продукт, готовый к применению. Другое дело, что он может и не покрывать все потребности потребителя. Как в Канаде, например HD себя позиционирует, насколько я понимаю, именно в данной ипостаси - по каким ключевым словам находится сайт? При этом, конечно, возможности ФБП намного шире, чем системы для бухучета. Сам занимаюсь инженернй задачей и вполне успешно Вполне уверен, что в одну форму (или ветку дерева) можно загнать вообще все. Только какова информативность записи при этом будет в журнале операций - максимум 12 слов/цифр из 9 символов каждое (см. настройки AAA). И именно поэтому возникают сложности и непонятки. И наоборот, если операция подробно сформулирована и размещена логически понятно для, ну пусть бухгалтера, то никаких трудностей не возникает. Например, мне абсолютна понятна и логически прозрачна настройка Тани Продан. В нашей настройке было около 1500 типовых операций и около 16000 строк в дереве. Верите, вопросы возникали не по бухгалтерским разделам, а по установкам ("а где у вас можно поменять количество, ставку, учетную политику?") Формулировки и логическое размещение операций это один, на наш взгляд, из ключевых моментов в реальных настройках! Было, что одну формулировку подбирали несколько дней - все не получалось понятно и логично (определяли опросом). Оно ведь как - пишешь и тебе самому все понятно, даешь посмотреть человеку со стороны и ... Это, впрочем, касается и написания руководств и инструкций. Одним словом если оперция сформулирована Касса-расход-выдача под отчет- 71-008 Звездин И.Б. то этим может воспользоваться пользователь практически любой квалификации. А вот если написано. условно говоря. ta-факты - W ON то ... А по-хорошему по этому поводу надо бы выслушать мнение реальных пользователей, а то мы рассуждаем стоя на берегу о технике плавания. С уважением, Игорь. P.S. А типовая конфигурация в 1С все-таки есть. Не говоря уже о спецконфигурациях типа "зарплата и кадры" . Для российского учета, во всяком случае.
|
| « Изменён в : 22.02.06 в 11:48:22 пользователем: IBZ » |
Зарегистрирован |
|
|
|
IBZ
 

Просмотреть Профиль | E-мэйл
Сообщений: 68
|
on 22.02.06 в 12:33:00, Alexander, Kiev wrote: А... адаптер Нового года уже не в счет? |
| В счет! Но имея адаптер, наверное, и много-много лет (с закрытием/открытием) сделать не так сложно. Ща схлопочу от А.Г. С уважением, Игорь.
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
on 22.02.06 в 11:37:42, IBZ wrote: Вполне уверен, что в одну форму (или ветку дерева) можно загнать вообще все. Только какова информативность записи при этом будет в журнале операций - максимум 12 слов/цифр из 9 символов каждое (см. настройки AAA). |
| Информативность может быть настолько высока, насколько далеко можно абстрагироваться от понятия значимости операции как носителя блока данных. В лобовой концепсии ФБП, вернее даже ее локальной версии, ветви дерева выполняют двойную функцию: Индекс типа операции(сильно избыточный) и аббревиатура призванная раскрывать ее функциональное содержание. Вторую можно разбить еще на две подфункции: при регистрации определить требуемый алгоритм обработки данных, при анализе осознать совокупность произведенных действий Ваши же слова, о сложности подбора оптимального словосочитания. В тоже время эти две особенности можно разделить, при маленьком условии - отказ рассматривать тело операции в качестве второй приведенной выше функции. К индексу типа операции прицепливается любой текстовый массив. Ну а о представления многообразия всех типов операции средствами всего нескольких графических форм думаю можно считать доказанным. Вот вам прекрасный пример разделения труда. ФБП-шная СУБД и независимое приложение на его основе. Многие наверное заметили, у меня к HD исчезли даже пожелания, потому как в существующей функциональности СУБД учетного направления она и так впереди всех.
|
|
Зарегистрирован |
С уважением, Александр.
|
|
|
|
|