The overall impression is that SAP is very good at co-development and co-innovation, and that they have some extremely talented people at all levels to make it happen - like architects, product managers , developers etc. More over, the leadership team at SAP sees a lot of value in these efforts, and gives a lot of personal attention. All that being said - there are somethings that have a good scope for improvement too.
SAP follows a very systematic process - they collect requirements or specifications, form use cases, compile a rough "features and functions list" etc. The result is a draft architecture - which then gets solidified into design specs etc, and eventually gets coded, tested and delivered. In theory - product managers, architects, developers etc work together throughout this process.
SAP is a product company - and thus they have a strong focus on standardization. For the most part, this is a good thing for SAP as well as other parties in the ecosystem like consultants, customers and such. However, like in all software development, standardization comes at a cost - sometimes a significant cost.
One of the major factors in architecture is determining what can be provided in the standard, and what needs to be implementation work in a project. Another important consideration is to determine what can be re-used from existing SAP functionality, and what needs to be developed from scratch. Let us examine these two considerations a little more in detail.
What goes into Standard?
The way we understood the process - If several customers use a certain functionality, SAP tries to put in standard. Otherwise it gets treated as implementation work. There are some other considerations too, but this seems to be the primary guiding principle.
This approach has some pitfalls.
1. SAP has to deliver the product in a defined time frame and within a budget. How many customers can they possibly talk to in that time? Will it be the same set of people from SAP who will talk to these customers ? and is it done face-to-face, through email, on phone, is it several customers together ? You get the idea - it is a difficult determination to make.
2. How does SAP take the call on whether a certain functionality is possible in standard or not? SAP being a complex system, very few people if any - will have sufficient depth and breadth in knowledge to make an exact determination if something can be done completely in standard or not. The risk here is that the people doing the overall design will make some decisions that might have to be completely reworked during development, and then rerto-fitted into the overall solution. The architects and product managers typically have a lot of experience in the core module they are developing, but it is not realistic to expect them to know every integration aspect to the same degree.we are convinced beyond doubt that they make every effort to get the required information from other experts within SAP, but given the constraints of time and resources and complexity of the solution, this is not a perfect or easy process.
Here is one potential solution that SAP can consider. Consultants/Partners are typically the people who have to eventually defend and evangelize the solution that SAP developers create. Consultants bring some real-world experience and breadth of knowledge that can readily compliment the depth of technical knowledge that SAP developers possess. That being the case, why is it that this big knowledge pool is not tapped to its fullest extent when SAP develops a product?
Consultants can typically answer for the most part whether a particular scenario is common across the industry. Consultants can also be tapped for testing the product. They can even suggest alternate design approaches due to their breadth of experience across other SAP modules etc. I readily agree that not all consultants possess this kind of knowledge, but definitely a large enough number of them do, and we are sure this group for the most part would be more than happy to contribute.
Ofcourse this is a two way street - in return of their contribution, consultants and partners should get something too - like an early sneak peek into the product, ongoing access to developers, training etc.
SCN already provides an excellent forum for consultants and partners. It is only a question of the point in time at which they can get involved in the product development. Currently, with a few exceptions, SCN lets consultants etc into the process only towards the end of the lifecycle. I would like to urge SAP to consider making this earlier.
What can be reused?
This is probably the most difficult part of the designer's role - be it in SAP or anything else. Having developed a lot of components in the past, SAP probably has a development framework for majority of the new products that they have on their plate.
Framework refers to different things to different people within SAP (and amongst consultants and partners etc). Sometimes, it refers to the underlying development model (like say 1order in CRM), and some one else might use it to refer to the UI framework for the product. There are many other definitions too. Most consultants explain inexplicable SAP behavior in projects as "it must be a buffer issue", and most SAP developers say "it must be a framework issue". Go figure !
The development framework is probably the biggest aspect to the re-use concept. Once you are commited to a framework, you get the good and the bad of that framework. Frameworks come with a certain encapsulation of functionality, so that developers can program more quickly, compared to using a lower level set of APIs. This is probably the right approach in theory for any product company, or for that matter for most customer projects. However, this can cause seious problems to the people who implement the solution eventually. On the other hand, for SAP to fix these problems - they probably have to let go of the abstraction of the framework and go a level or two deeper, and this is a costly and error prone process if attempted in a short time.
Personally, We think these kinds of restrictions were put in place primarily because the folks who developed the development model didn't get sufficient input from "the field", or maybe they were pressed for time. Unless you talk all the time to people who will actually use the system (as opposed to talking only to other experts within the organization) , it is impossible to come up with a solution that will be accepted in the marketplace. This lesson is equally applicable in implementation projects as well . we are sure there are a lot of us with battle scars to prove it !
We do see that SAP is changing its approach and are more serious about co-innovation and co-development these days. The new UI in CRM is a perfect example that they are listening to the concerns of the market. We are sure that SCN is also getting evangelized within the SAP development organization. In eSOA spcae, SAP has some real good investments in partner programs.
These are all positive steps in the right direction. we are looking forward to even greater co-opeartion between SAP and other players in the ecosystem.
No comments:
Post a Comment