需求决定产品.
而一个产品是否优秀，取决于曾经面临过多少需求.
对于以上观点深度同意! 所以R/3 比较值钱了

于是应该清醒地认识到，SDK对于你的解决方案其实并没有什么意义.所谓企业定制,根本和什么SDK无关，定制是在那个OBS系统上实现的.

那个OBS系统,就是传说中的AddOn,去掉界面皮肤，根本就和SDK没什么关系,完全来自于另外一个独立的开发项目.通常是.net..

关于以上观点极不认同， OBS是定制过程产生的产品(或模块)
它是基于SDK的，没有SDK，OBS怎么来的？完全独立的？
它是在调用SDK呀，SDK时时时刻刻在工作，没SDK，就没会什么Addon了

SDK不会直接生成解决方案，它仅仅是生产解决方案的平台和工具!

只有脱离SBO的业务对象，直接读写数据库，才算相对独立的
但那就没有讨论的必要了，依照这个理论，你可以完全创建一个
新的ERP系统

其实，我的意思是说,定制过程产生的产品，真正工作的是产品本身内部的算法及其流程.这个算法是基于.net或其他开发平台的


在这里,SDK只负责最基本的数据和界面的传递工作.

因此对一套AddOn来说，对SDK的应用并没有太多值得去考核的地方,应该被考核的是AddOn本身(用.NET或其他语言)编写的算法和流程.

所以最后决定AddOn质量的是另外一个独立的软件开发项目.而客户(甚至Sales)容易产生误解的是因为看见了"SDK"这个词,而自然地认为SBO的开发比其他定制开发更有针对性.
其实SBO的开发和任何软件的定制开发并没有非常多的不同.(这也是自然的,否则就是开源软件了)

----------------------------------------

话分两头,如果对SBO熟悉到了可以亲自来完成这种数据或界面传递的话,SDK就可以不用了.
而导致开发人员这样做的动力是来自DI和UI为了保护SAP数据而缺少的一些功能.

(比如对单据的一些特殊操作,DI应该还不能完全模拟出来.而象UI里矩阵之类的控件还存有很大的局限性,加之SBO的数据结构简单且清晰,因此很可能导致开发人员一怒之下踢开党委闹革命.....)


SBO的确提供了一种办法，使一种定制能脱离SBO对象而直接读写数据库....那就是.....强悍的"查询接口".....

这一类定制,不但抛弃了SDK的UI与DI,同时也一起抛弃了.NET这样的开发平台.

直接用自定义表,视图,存储过程与函数这类数据库对象,通过SQL在SBO的"查询管理器"中完成功能上的定制.

也许这就是传说中的第四代编程语言开发吧.......

这一类定制开发的好处在于
开发效率更高,避开了SDK的数据保护,既提升了用户体验，也降低了开发成本.
运行效率更高,至少每个用户可以省不少内存

缺点在于
门槛很低,谁都会做一个,但对经验值的要求太高，想做出来能用很难...甚至有一定危险性
交互界面不够友好
缺乏版权保护
维护成本过高

对比之下可以看到，除了版权问题之外,其实任何定制开发都会有上面的优缺点,所以我才会认为在SBO定制中,SDK是否参与其实对项目影响是有限的.它们都是一个独立的软件开发项目.小到增加一个按钮,大到重新开发新的ERP系统.项目管理的路数是一样的.

这里好热烈阿，哈哈

我是觉得对于中小企业来说，尤其整个项目的资源不是很充分的情况下，能不开发就不开发，如果各个方面资源十分的充分不论是客户方还是实施方，那尽可能的去满足需求也未尝不可（前者情况多一些应该是，利用B1来提高一些管理水平还是做得到的）。当然这里有一个大前提就是项目的目标要明确，有时候项目的大目标直指SBO功能比较弱的地方（比方说客户是想利用ERP来帮助生产计划的），那只能感叹选型的时候就已经走错了一大步，开发多了，带给双方的风险都是不小的。个人认为SBO已经算的上是一个灵活的系统了，非常的易用，也很容易理解，灵活是用来弥补功能的不足，用来对应中小企业变化快的特点的，这一点定位还是很合理的，同时也控制了SBO本身的成本，让中小企业客户更易于接受

DACHU  你根本没有仔细的在 看 Link 的文字 .  还要回帖子, 真是莫大的 浪费.   说明你不认真.  

    Link 讲的非常的清楚, 我以前不明白SDK 的结构, 还以为它真的是个平台, 看了 这个分析, 才知道它不能被称作是 平台.  所以这个 AddOn是另外一个独立的软件开发项目 说的一点不错的.


  而且也决定了 BOne的代理商一定要有比较强的开发, 要不根本玩不了. 但是这也增加了项目的成本. 很容易把豆腐搅成肉价钱.

   DI  ----  Data Interface
  UI------  Utility Interface ????    Useness Interface???

  SDK -- 是什么的简写 ?

    还有对开发的态度, 其实不仅仅是 Bone,  所有 号称有平台的, 能低成本开发的 ERP 全都面临这个问题.  早上我们还在讨论这个问题.  

     我属于比较心慈手软的一类, 比较没立场, 虽然在客户那边面对需求,说 这个真的开发就要 收费,  或者说这样成本太高了, 不纳入系统,  但是真的回来内部讨论了, 我还是会站在客户的立场上说服做这个开发, 因为顾问就是在成本范围内"让客户满意", 而且我认为 客户满意比成本更重要.  中国人不是说 吃亏就是福么 ,  不是喜欢长期的关系么.  那么现在我们可以退一步.

    但是经理就是坚持:
   1   No free.
   2  Less customerlization.
   3  Close project soon.,  pay soon.

  他不理解我说的 长期关系 和 吃亏是福 的理论.  所以对于客户满意 这 4个字, 我真的很疑惑.


     Link 怎么这么老道啊, 做了很久么??  佩服.

首先，声明一点：我是仔细看完，经过思想并认真回复的，这一点是别人无法下定论的!
至于分歧，我想可能看事件的角度不一样吧，
我做开发出身的，做自己开发的产品实施与做别人的产品实施可能有着本质的不同吧!
自己的产品会有足够的了解，只要知道它的缺陷，就会极力的完善，
使用自己的产品达到需求目标，
而实施另人的产品，基于对产品的理解程度，我想会有一种天然的回避心理，再基于利润最大化的因素，就造成了另外一种工作风格了

关于“平台”

我不知道大家怎么理解的？
SDK(Software development kit) 软件开发工具包，直接从字面理解，SDK的表达很清楚：
是一个开发的工具，或者理解一个运行代码的平台，它不实现什么业务功能!
如果从业务上理解的话，跟你的实施没有一点关系! 如果从这个角度来讲的话，它确实是“独立”的，
但是反过来说：
UI API (User Interface API)  是负责用户界面及用户操作体验的，保持了与B1的一致风格，它们是有关联的
DI API (Data Interface API )那就更不用说了，它封装大部分的业务对象，你所操作的业务数据都是由它来实现，只有通过DI的操作，你才能保持业务对象数据的一致性(当然如何你是B1的系统分析及设计者，可能例外)
基于UI或DI上开发的产品，你能说它跟B1是独立的，至少数据是关联的吧

关于“立场”

如果，你想挣的是实施的钱，那就没有必要讨论SDK了，毕竟项目的完成和项目的完善，在付出上是有一定差距的!
Addon的开发不是一个捎带脚的角色，它也应该是严肃的、专业的、系统的工作!
如果开发能力有限的话，就不要勉为其难，有人说过 Say NO 是跟能力有一定关系的

开发人员的综合素质应该在一般实施人员之上，没有对产品及项目的深入理解，开发
出的产品就不一定能保证质量，那样肯定会影响项目实施，造成成本增加

我不是一味的极力去推行开发，但是做为一个定位于中小企业的软件真是无法满足客户
千变万化，千奇百怪的需求呀，B1的优秀之处就是提供了一个开发的平台，给你完善
业务需求提供了一个机会，其关健是你能不能掌握、(适度)善用这个工具。

另外，我也同意开发不是免费的，有付出就应该有回报! 这一条到哪都适用

[QUOTE]最初由 瓷骨MM 发布

    但是经理就是坚持:
   1   No free.
   2  Less customerlization.
   3  Close project soon.,  pay soon.

  他不理解我说的 长期关系 和 吃亏是福 的理论.  所以对于客户满意 这 4个字, 我真的很疑惑.
QUOTE]

一个"优秀"的项目经理   哈哈

至少他理解资金和成本的关系