|
|
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Папа Карло что лизинг кластерного апплекейшен сервера стоит 375 доллраов в месяц, лизинг кластерного датабаз сервера с тем-же числом процов и памяти и единственным отличием raid10 стоит 3500 долларов в месяц... Вы себе плохо представляете уровень контор, в которых ставятся такие системы. Пятнашку за выделенный под задачу сервак это не вопрос. что увеличении прибыли идет за счет уменьшения издержек, а не зчет увеличения продаж Это кто Вам такую глупость сказал??? Cost Cutting вещь очень лукавая - в долгосрочной перспективе можно бизнес загубить. И лично к Вам вопрос: вами была реализован проект расчета Российской з/п? 2 ASCRUS .... по которым например сотрудники вошедшие в одну ведомость не имеют права входить в другую В бытность работы на гос предприятии я получал з/п по нескольким ведомостям.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 12:43 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Нет, ну просто не могу не удержаться от комментария... Человек довольно грамотно и инженерно описывает выбранную им технологию с учетом постановки задачи. А в ответ несется - да это все фуфло, если на сто тыщ человек запустить, долго будет, а вот 3-х звенка - магическое слово! - все летать будет!!! Как будто от одного названия уже все ускоряется. И - интересно услышать - где это у нас есть организации в которых 100 000 чел работает? Даже на Форде, кажется, порядка 40 тыс. - но это консорциум из нескольких компаний, филиалов и пр., и уж явно зарплата там не считается сразу для всех. 2 ASCRUS Меня интересовало несколько иное. Как я понял, в описанной вами реализации, история ведется по отдельным независимым сущностям, включающим один измен. атрибут - ставка, тариф и пр. Это относительно просто. Сложнее, когда есть набор атрибутов (полей), каждое из которых может изменяться отдельно от остальных. Пример - атрибуты сотрудника - ФИО, паспортн. данные, место жительства, должность. Каждое это поле меняется независимо от др. А получать надо связанный набор. А если учесть, что поля могут менять задним числом, то вообще кавардак. Напр., у Иванова задним числом поменяли адрес, а потом - еще более ранним - паспорт. Необходимо на заданную дату вернуть правильные значения. Общим решением явлется хранение атрибутов по записям, - однако.... Это сильно усложняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 13:06 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Varivan Угу, есть такое дело. Имелось в виду, что необязательно например в середине месяца, после выдачи приказа о начислении и выдачи межрасчетов какой то премии все сотрудники тут же попадут в ведомость и получат деньги в кассе. Нормальная ситуация, когда по мере пополнения денег в кассе они будут ее получать, причем не обязательно целыми отделами - например в тех же гос. конторах реальна ситуация, когда впервую очередь денежки получит начальство. С другой стороны человек, уже попавший в ведомость начинает считаться как деньги получивший по данной ведомости и соотвественно при дальнейшей порционной распечатке оставшихся сотрудников войти уже в такую ведомость не может, иначе бы такую ведомость пришлось бы депонировать. С другой стороны любая попытка изменения размера премии сотрудника, уже вошедшего в ведомость приведет к запросу о подтверждении аннулирования ведомости, что приведет к тому, что вся ведомость, в которой этот сотрудник входил будет считаться не действительной, и все сотрудники, которые в нее входили окажутся в статусе не получивших деньги, и при любой попытке запуска окончательного расчета система выдаст ошибку о невыдаче денег перечисленным сотрудникам и расчетчику зп придется сделать выбор между снятием межрасчетных выплат с этих сотрудников или же распечаткой требуемой ведомости. То же самое касается и окончательного расчета, пока все что должно быть распечатано не будет распечатано и все деньги не будут полностью распределены по всем потокам оплат (касса, кредитки, сбербанк, почта и т.д.), расчетчик зп не сможет закрыть текущий расчетный месяц и перейти на следующий. Однако это ограничение не повлияет на тех бухгалтеров, которые во время уже распечатали отчетные формы - в системе поддерживается ввод данных и будующим числом, так что они спокойно даже при открытом пока предыдущем расчетном месяце смогут начинать вносить входящие данные нового расчетного месяца, пока их нерасторопный коллега будет печатать отчетные формы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 13:08 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
aag Для меня все таки самое простое решение хранить аттрибуты в одной таблице. Все таки они все описывают изменение свойств одного обьекта и на любой промежуток времени однозначно будут его характеризовать. Т.е. у меня например на код дохода реально получается 2 таблицы: 1. Сам обьект дохода, в котором стоит его ID и логическое наименование 2. Таблица аттрибутов кода дохода, в которой на каждый ID кода может существовать запись, хранящая с указанного периода времени аттрибуты обьекта - налоговый код дохода, код материальной скидки и сумму материальной скидки. Фактически любой из этих параметров может измениться вне зависимости от остальных. Физически получается что изменение например суммы скидки приведет к появлению еще одной записи с дублирующими полями кода дохода и кода скидки и новым значением суммы скидки. Можно ли это считать денормализацией данных ? Честно говоря не знаю. Тут уже все зависит только от предполагаемого обьема данных. Для обьектов с нечасто изменяющимися аттрибутами это нормально. Указанный Вами пример тоже идеально подходит под такую модель - ФИО или номер паспорта меняются настолько редко и у малого кол-ва граждан. Если бы была постановка с частыми изменениями некоторого числа аттрибутов, то скорее всего для таких аттрибутов пришлось бы делать свои таблицы, где в каждом конкретном случае решать как их хранить - по записям или же по таблице на конкретный аттрибут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 13:25 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS если честно, то почти ничего не понял :)) но к этому и не стремился :) Главное, что Вас не смутило найденное дилетантом в расчете з/п противоречие :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 13:29 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
А мне нравится. Попытаюсь приложить данную идею немного в другом разрезе. Есть ПО обеспечивающее несколько организаций, в каждой из которых свои особенности. Попытка сделать программу универсальной и разбежаться за счет параметризации на этапе инициализации сегодня привела к диким затруднениям на этапе сопровождения. Здесь вопрос решается на уровне запуска своего алгоритма, реализующего особенности данной организации в ПО, имеющем 90% общего программного кода. С точки зрения сопровождения это хорошо тем, что в общую часть ПО изменения вносятся крайне редко, а отладка каждого отдельного алгоритма позволяет работать с одной организацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 13:45 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Еще дополнение - зп не большая, а сложная система. У любой системы должны быть границы. Чисто теоретически я мог бы изначально проектировать зп для расчета заработной платы всех жителей Китая, но такой задачи слава тебе господи и не ставилось чо то не совсем понял почему все привязалась именно к з/п предприятия ? или система не предназначена только для РФ и только для ЗАО такое-то ?? а зарплата в финансовых пирамидах, там 40 тыс участников - детство ... ИМХО примерно то же самое я наблюдал у кабельной сети, у них там так-же куча услуг, туча клиентов которые оплачивают часть , по ценам зависещим от погоды на этой неделе со скидками от балды. может логика менее сложная но суть таже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 14:00 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Расчет заработной платы - вполне конкретная часть трудового кодекса РФ, регулирующего трудовые отношения между работодателями и работниками, и описывающего порядок расчетов за выполненные обьемы работ, удержания действующих налогов и соц. норм. Насколько я понимаю клиенты кабельного телевидения или же финансовые пирамиды регулируются другим законодательством, описывающим отношения на договорной основе как юридического и физического лица, со всеми вытекающими отсюда условиями. Нельзя же в самом деле тех же клиентов банка причислить к числу его сотрудников только за то, что они хранят в нем свои вклады и получают с этого проценты. Это другая постановка, соотвествующе и другая задача. При всем желании универсально сделать бы и не получилось. Наглядный пример попыток универсальной постановки можно легко наблюдать в комплексных бух. системах, в которых расчет зп всегда являлся самым слабым местом и мягко говоря расчитан на "идеальное" предприятие без отклонений от схемы "все положенное время отработал, деньги получил", только по той причине, что реализован в них расчет зп на основе движков, расчитаннных на бухгалтерию. Это конечно круто начисления и удержания хранить и обрабатывать дебетом и кредитом, но ни к чему хорошему это не приводит. Мое мнение - программа должна быть гибкой в реализации и сопровождении, но с четко описанной постановкой и областью применения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 14:19 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
а я то не в РФ, что из-за этого я не могу применять твои методы для решения задач вне РФ ? ну законодательство чуть другое, ну не сотрудников а клиентов общитываю ... не вижу принципиальной разницы. ну да ладно, дальше вижу только религиозный спор ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 16:24 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Так а кто мешает написать свою задачу, пользуясь приведенными мною решениями, если они конечно понадобятся в контексте поставленной задачи ? Насчет же распостранения проекта зп вне России я честно говоря не уверен, что может получится. Одно дело, когда просто расчеты изменяются, другое дело, когда структура входящей, расчетной и исходящей информации будет своей для каждой страны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 16:36 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Вот! Свет истины. :-) Именно такую стуктуру я и пытался обрисовать. Но, недостатки данного подхода также очевидны. Напр., сделать селект по таблице кода доходов - со всеми атрибутами. Это выливается в необходимость конструирования такой таблицы - через врем. таблицы, update полей и пр. Если нет возможности дать гранты на паблик на все треб. таблицы (а как правило ее нет) - динамический SQL невозможен. Итого - куча кода, медленные запросы. Поскольку в недалеком будущем это предстоит и мне, вот я и жалуюсь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 16:46 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Именно такую стуктуру я и пытался обрисовать. Но, недостатки данного подхода также очевидны. Напр., сделать селект по таблице кода доходов - со всеми атрибутами. Это выливается в необходимость конструирования такой таблицы - через врем. таблицы, update полей и пр. Если нет возможности дать гранты на паблик на все треб. таблицы (а как правило ее нет) - динамический SQL невозможен. Итого - куча кода, медленные запросы. Наверное мы все таки друг друга не поняли. Приведу пример использования справочника кодов доходов: Код: plaintext 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. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. Ну и в том же духе можно продолжать писать скрипты изменения аттрибутов у множества кодов доходов, ХП, реализующих это и т.д. У меня клиентская часть посредством кэшированных изменений все проводимые изменения проводит через ХП, которые сами и решают, что, как и куда добавить, изменить или удалить. Как видно ни о каком динамическом SQL, конструировании таблиц, и т.д. тут речи и не идет. Основными недостатоками моей модели являются избыточное хранение аттрибутов и некоторая сложность в их обработке. Однако все равно это не идет ни в какое сравнение с хранением аттрибутов по записям, где действительно все будет выглядеть, как стоп-кран в СУБД. Предложенная мной модель не позволяет хранить обьекты с изменяющимся и неизвестным кол-вом аттрибутов, однако мое личное мнение, что если такое требование существует, то это скорее всего указывает на неправильно спроектированную архитектуру БД. Реально при описании базы данных можно редко встретить необходимость хранения обьектов с неизвестным кол-вом аттрибутов и прикручивать это на СУБД печально, так как под это релляционные СУБД не предназначенны. В основном я встречал с попытками сделать такое людей, у которых была "светлая мечта" сделать универсальный проект, не зависящий от постановки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 18:41 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Хех - вроде все проверил, но все равно ошибки в скрипте допустил. После Код: plaintext 1. 2. необходимо поставить Код: plaintext Вместо Код: plaintext 1. 2. 3. 4. 5. 6. 7. Конечно же Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Вроде больше ошибок нигде, кроме очепяток :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 18:47 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Varivan что лизинг кластерного апплекейшен сервера стоит 375 доллраов в месяц, лизинг кластерного датабаз сервера с тем-же числом процов и памяти и единственным отличием raid10 стоит 3500 долларов в месяц... Вы себе плохо представляете уровень контор, в которых ставятся такие системы. Пятнашку за выделенный под задачу сервак это не вопрос. В Российском банке мы тоже техники на поллимона покупали в год. :) На Западе не везде тратят деньги как в России. :) что увеличении прибыли идет за счет уменьшения издержек, а не зчет увеличения продаж Это кто Вам такую глупость сказал??? Cost Cutting вещь очень лукавая - в долгосрочной перспективе можно бизнес загубить. Загубить можно что угодно. :) Давайте лучше посчитаем. :) Пусть издержки на производство продукта А составляют 1000 рублей в месяц. Мы прибыльная компания и продаем на 1500 рублей в месяц. Итого мы имеем 50% прибыли от вложенных денег. Теперь представим что мы продали на одну копию больше и теперь у нас не 1500 рублей, а 1700 рублей. Итого мы получили 70% процентов от вложения наших средств. Теперь предположим что мы уменьшили издержки на ту же сумму. Т.е. теперь мы тратим 800 рублей на производство и получаем все те-же 1500. Мы получили 87% прибыли. Что в принципе далеко не плохо. :) я, разумеется, могу ошибаться. :) ко всему надо подходить с головой. при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне. вроде вот так. теперь с примерами если можно "почему это глупость". прошу прояснить ситуация не для того чтобы спорить, просто хочу знать больше подходов и получить больше опыта. И лично к Вам вопрос: вами была реализован проект расчета Российской з/п? нет. в России я работал в банке но занимался другими вещами... хотя те же грабли с постоянно изменяющимяся положениями ЦБ. Переводил банк на новый план счетов и деноменированные рубли. Именно поэтому я не говорю что хорошо и что плохо в той конкретной реализации что сделана ASCRUS. Он сам кузнец мне все равно. Просто в этом треде спорят о том что лучше трезвенка или двузвенка. Ответ мой будет такой: когда как. Как я уже писАл все зависит от конкретной задачи. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 20:09 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
aag Нет, ну просто не могу не удержаться от комментария... Человек довольно грамотно и инженерно описывает выбранную им технологию с учетом постановки задачи. А в ответ несется - да это все фуфло, если на сто тыщ человек запустить, долго будет, а вот 3-х звенка - магическое слово! - все летать будет!!! Как будто от одного названия уже все ускоряется. И - интересно услышать - где это у нас есть организации в которых 100 000 чел работает? Даже на Форде, кажется, порядка 40 тыс. - но это консорциум из нескольких компаний, филиалов и пр., и уж явно зарплата там не считается сразу для всех. не надо быть таким радикальным. :) да каждый использует то, что он уже знает. знает только трезвенку будет только трезвенка. :) У меня был плохой опыт с двузвенной технологией когда был куплен софт в бан за 1млн. баксов и он не смог потянуть 150 (сто пятьдесят) операционистов. вот это был сакс. :( трезвенки пока всегда работали. следует ли из этого что трезвека лучше двузвенки? НЕТ! :) Это как в анекдоте: - Вы любите кошек? - Нет! - А! Вы их просто готовить не умеете. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 20:13 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Реально при описании базы данных можно редко встретить необходимость хранения обьектов с неизвестным кол-вом аттрибутов и прикручивать это на СУБД печально, так как под это релляционные СУБД не предназначенны. В основном я встречал с попытками сделать такое людей, у которых была "светлая мечта" сделать универсальный проект, не зависящий от постановки. есть метамоделирование и трансформация метамоделей. вот тут запросто можно получить известное число аттрибутов, то число объектов и аттрибутов у этих объектов не ограничено. а признаком хорошей метамодели является не изменении ее схемы при добавлении новых элементов. это было так к слову. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 23:02 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 папа Карло При наличии одного компьютера на сервере приложений очевидного (!) выиграша в производительности трехзвенки нет. Это по-моему, если есть - поправьте. Более того, при отсутствии правильного кеширования данных на сервере приложений будет явный проигрыш (но при наличии может быть выигрыш). Преимущества трехзвенной архитектуры в скорости (масштабируемости) неоспоримо проявляются ИМХО только при наличии параллельно работающих серверов приложений. При этом опять же, необходимо правильно спланировать кеши данных, иначе один медленный сервер БД съест весь выигрыш. Но планировать кеш на параллельных серверах, это та еще задача, покруче даже расчета зарплаты, особенно при лоад балансе. Этот кэш ведь нужно постоянно реплицировать между серверами. И потом масштаб задачи явно не тот, чтоб ставить параллельные сервера приложений. В общем большая куча дополнительных проблем, которых уважаемый докладчик счастливо избежал. Так что по-моему по архитектуре все сделано правильно. Насчет гугла, работающего на четверках. Этот аргумент я слышал много раз. Но это же вообще другой класс задач: чистый ОЛТП, медленно меняющаяся база данных, которую можно реплицировать раз в неделю, поток данных в одну сторону - только селекты, об актуальности данных речи нет вообще, более того, никаких пользовательских сессий, прав доступа, транзакций, целостности данных и т.д. Машины гугла просто работают параллельно ничего не зная друг о друге. Вот потому и четверок достаточно, нужно только, чтоб их было достаточно много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2003, 06:31 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
При наличии одного компьютера на сервере приложений очевидного (!) выиграша в производительности трехзвенки нет. итак у меня выделеный AS, в нем в виде объекта в памяти наш кеш. думаю этот кеш весь влезет в гиг памяти, если нет покупаем еще, благо цена памяти в районе цены мешка картошки. в крайнем случае сваливается в своп который имхо для подобной задачи более эфективен субд. dom-xml например забавно кеширует свои объекты. А в субд это у нас плоские таблицы которые нада считать с диска и преоброзовать чтобы провести вычисления. p.s. а про гугл вы не в ту степь, во первых это не рсубд, во вторых думаю там объем такой что о репликации речь не может идти ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 12:08 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
>> При наличии одного компьютера на сервере приложений очевидного (!) >> выиграша в производительности трехзвенки нет. Возьмем более сложный вариант. Два компьютера. Имеются расчеты, которые выполнить за короткое время почему-то не удается. Пусть даже кривые руки программиста в этом виноваты. Но такие расчеты имеются. Что мы при этом имеем на клиент-сервере: один пользователь запускает такой расчет и идет пить кофе, а второй может спокойно составить ему компанию, потому-что радости от тормозов на сервере он явно не получит. Что мы имеем с 3-х звенкой: один пользователь выгребает на свою тачку (где у него установлен средний слой) нужные ему данные запускает расчет и идет пить кофе, а второй продолжает работать как ни в чем ни бывало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 13:50 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 папа Карло каждый использует то, что он уже знает. знает только трезвенку будет только трезвенка Именно поэтому, руководитель проекта должен четко представлять где, что использовать и подбирать людей с соответствующими знаниями. Хотя, по-моему, если человек знает 3-х звенку - но при этом не знает обычного клиент-сервера, это не есть хорошо. Что касается вашего опыта - видимо, был закуплен такой удачный софт. Могу привести обратный пример - MSSQL 6.5 тянул порядка 400-500 клиентов, до 20 активных. 2 xtony Кривые руки программиста что угодно загубят. На практике, в правильно спроектированных клиент-серверных системах, такого влияния одного расчета на всех нет. Я не против 3-х звенки! Но данная тема переросла в споры о ней, хотя посвящена была системам с гибким алгоритмом. 2 ASCRUS Да, в вашем случае, наверно достаточно обойтись такой реализации истории. Однако необходимость же хранения сущностей с произвольным кол-вом атрибутов весьма актуальна - если не рассматривать такую сущность как основу базу, а напр., как вспомогательный информ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 16:30 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Папа Карло Загубить можно что угодно. :) Давайте лучше посчитаем. :) Давайте, считаем: Пусть издержки на производство продукта А составляют 1000 рублей в месяц. Затраты постоянные или переменные? Мы прибыльная компания и продаем на 1500 рублей в месяц. Итого мы имеем 50% прибыли от вложенных денег. Теперь представим что мы продали на одну копию больше и теперь у нас не 1500 рублей, а 1700 рублей.Итого мы получили 70% процентов от вложения наших средств. А это зависит от вида затрат. Теперь предположим что мы уменьшили издержки на ту же сумму. За счет чего? Т.е. теперь мы тратим 800 рублей на производство и получаем все те-же 1500. так за счет чего мы издержки снизили? А не уменьшилось ли у нас качество при этом? Не нанесли ли мы урон бренду (компании или продуктовому)? Не упадут ли у нас продажи через 3 месяца, после сокращения этих издержек? Мы получили 87% прибыли. Что в принципе далеко не плохо. :) Опять же зависит от вида издержек. я, разумеется, могу ошибаться. :) Ваш расчет верен только математически (при вычислении процентов). К реальной жизни он имеет очень слабое отношение. теперь с примерами если можно "почему это глупость". прошу прояснить ситуация не для того чтобы спорить, просто хочу знать больше подходов и получить больше опыта. см. выше. Если интересно развить тему с целью получения опыта - предлагаю вынести в отдельный топик. нет. Именно поэтому я не говорю что хорошо и что плохо в той конкретной реализации что сделана ASCRUS. Он сам кузнец мне все равно.... Вопрос снят :) Значит мне показалось, что Вы слишком уж рьяно критиковали решение ASCRUS :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 19:22 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Varivan: Ну как всегда! :) читаем только то, что хотим прочитать. написал же: "при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне" Вы меня спрашиваете про качество итд. Ответ такой: При моделировании ситуации мы отбрасываем все не нужное, то что в рассмотрении ситуации роли не играет. Надеюсь с этим никто спорить не будет? ;) Так вот когда я "смоделировал" ту ситуацию то посчитал (принял за условие) что все остальное что не оговорено в условиях остается в том-же состоянии (это у меня по дефолту). Т.е. качество не страдает. разумеется. :) Почему качество не страдает? Ответ очевиден: у любого нормального продукта есть требования. Когда продукт отвечает тем требованиям то он качественен. Пример: по требованиям система должна иметь максимальное время запроса-ответа до 10ти секунд. Система при проектировании человеком А показывает величину 1 секунда за запрос-ответ и операционная стоимость состовляет 1000 рублей в месяц. Система при проектировании человеком Б показывает величину 1.5 секунды за запрос-ответ и операционная стоимость состовляет 800 рублей в месяц. Как Вы понимаете быджет на разработку фиксированный и равен в случае А и Б. У меня вопрос к Вам: по какому пути Вы пойдете? Ваш расчет верен только математически (при вычислении процентов). К реальной жизни он имеет очень слабое отношение. Так-же... примеры расчетов Вы мне так и не привели. Хотябы даже очевидных для меня. :( Где пример из жизни: типа мы снизили - получилось вот так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 21:59 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
2 Папа карло "при верхних расчетах подразумевается что уменьшение издержек произошло за счет изменения дизайна системы на начальном уровне" Мы вроде говорили про производства абстрактного продукта "А"? ПРичем тут дизайн системы? Так вот когда я "смоделировал" ту ситуацию то посчитал (принял за условие) что все остальное что не оговорено в условиях остается в том-же состоянии (это у меня по дефолту). Т.е. качество не страдает. разумеется. :) Вы поставили очень серьезное ограничение для своей модели. Издержки всегда снижаются за счет чего-то. Другое дело, что мы можем осознанно пожертвовать чем-то для снижения издержек, но каждый конкретный случай надо рассматривать отдельно. Правила тут, к сожелнию не выведешь. Так-же... примеры расчетов Вы мне так и не привели. посмотрите на наши (Российские) продуктовые бренды (хотя, ИМХО, сейчас ситуация меняется....). Есть период вывода бренда на рынок, когда соотношение цена/качество очень привлекательное. Когда бренд раскручивается и пользуется популярностью, резко снижают издержки (и как следствие качество) и бренд "выдаивается". Через какое-то время бренд с рынка уходит, собрав сливки и выпускается новый. Но эта процедура вполне осознанная и просчитанная программа. А если мы снизим издержки не вовремя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 22:11 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
Varivan: Удивительная способность игнорировать вопросы..... :( так по какому пути Вы пойдете? Для того, чтобы говорить что внутри бренда уменьшались издержки надо было там быть. Я там не был, поэтому говорить так не могу. У вас есть конкретные примеры из Вашей практики? Если есть то хотелось бы услышать "без имен" как это было, если нет, то так и скажите что то что вы говорить основано на теории и практики нет. Ну дык? Да, дабы не быть голословным можно обозначить Ваше положение в компании чтобы понять угол зрения с которого сделанны выводы. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 23:03 |
|
||
|
Система с изменяющимися алгоритмами расчета.
|
|||
|---|---|---|---|
|
#18+
да..... я могу снижать издержки на столько на сколько смогу в рамках бюджета и требований проекта. Т.е. я не могу перерасходовать бюджет. И могу "ухудшать" продукт в рамках требований (пример что я привел). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 23:06 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32199895&tid=1545034]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
156ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 458ms |

| 0 / 0 |
