on 2007 Jul 19 7:07 AM
Hi, Guys!
I have to tell you that I' m getting completely nuts these days with my job - maybe you can help me back to get my feet back on the ground.
As part of a very large portal project, we' re working on ESS/MSS implmentation - no, let' s forget about the terms ESS/MSS and better speak about customer processes which are derived from standard, but don' t have really anything to do with it any more.
We' re facing so many specific customer requirements that we have totally left the SAPs standard and are have now more or less to develop the whole thing from the scratch - making SAP the most expensive compiler worldwide.
As we' re working in Portal environment and simply delivering applications to be integrated, there are lots of technologies to choose from - WDA/WDJ, CAF Core/Visual Composer, GP/Workflow, Adobe Forms via NWDS/SFP, Creation of navigation structures via Homepage Framework or completely within Portal Content Studio.
So, the reason why I marked this thread as question and not as sigh of dispair is: Where is the ultimative guide telling me which implementation technology to use under which circumstance? Which technology is the most mature, which the most future-proof?
Don' t tell me the good old "There' s different cutlery for different dishes. Use knife, spoon, fork where it fits!" By now, there are so many different aspects to consider with each implementation technology decision - SOA-compliance, SAP-support, configuration/enhancement possibilites, Portal/Backend integration - that a simple development consultant like me is completely overstrained. I mean: Of what use e.g. is the best SOA-technique like CAF if all backend logic is found in reports like in SAP HR? How do we then integrate these applications? With ITS?
So, again: Where is the universal answer to all this?
Regards,
Thomas
The answer is to change the process and not the system
I am looking at doing some work with Portals and would be interested to see which area I should be looking at!
Also, I guess alot may depend on the landscape and what the developers feel comfortable using.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oh, you' re so right! Standardized Software requires standardized processes - configurable in a way, but not to be turned inside out. But guess what: Public sector - and this is what we' re talking about - doesn' t care about common-sense.
There are interests to be safeguarded, task forces to be set up, people to be kept busy, notifications to be issued and money to be spent!
You know what really scares me?
In our application we now seem to be meeting the boundaries of SAP in many ways.
The complexity of configuration - if still procurable - required to fulfill the many different requirements of many different departments,offices a.s.o. exceeds the costs of new implementation by far.
SAPs salesforce is bombing the different decision-makers with their newest comforts and strategies, We' re already running half a dozen different programming models - BSP, JSP, WDJ, WDA, Workflow, Webflow - now GP, CAF, MI - and there seems no end (Enterprise Search, AS 7.1 and all the other stuff).
Not only the Basis guys are facing a sincere "Lack of Know How"-desaster, also here in development we don' t know where to get time or staff to extend BSP-, JSP- and Web Dynpro-based Standard-applications, deal with new Interactive Forms a.s.o.
Complete breackdown is just a matter of time!
This is not specific to Public Sector...
I am working on a European Roll out for a major international company.
Savings are going to be made by standardising the processes across the whole of Europe..
All good so far... Apart from.. No design was signed off. Each country wants their own thing. nothing is sap standard! A different company supports the current SAP implemenation and won't let us on the system. Other than that, we are on track -albeit 4 months late....
What can I say! It keeps me in work!
Good luck with your Project....
marilyn,
to cite barry, '<b>this is not specific to public sector</b>' !
IMHO, this is a general IT problem, especially relevant to SAP with its dynamics and diversification with respect to technologies.
Therefore this is a very important discussion to be held in a general place. Maybe Coffee Corner is too informal but 'Public Sector' would be too narrow.
regards, anton
Message was edited by:
Anton Wenzelhuemer
Hi, Marilyn!
The reasons I used this forum for my question was that it seemed quite philosophical and in its general nature not really precise enough to be categorized in any other one.
IMHO Barrys and Antons contributions really address some serious problems. In our company - which in this special case kind of stands for our whole country - I think SAP has been chosen for a lot of reasons. Its maturity, homogeneity and the possibility to adapt it to special requirements easily. In the end - as everywhere - it promised to run daily business better and cheaper than before.
The first two benefits were abolished by SAP itself with introducing a lot of new, half-baken products (MDM, x... product series) which do not nearly meet the expectations customers had regarding correctness and operability as well as bombing the technology scene as well as its customers minds with dozens of new plattforms and frameworks each declaring all previous ones as obsolete (Web Dynpro and BSP - only to name the most inglorious one).
So by now, instead of running a homogenous, stable system of a piece, we' re still struggling with pitty standard-programming in ABAP, introducing completeley new products like e-Learning made of old stuff like BSP, implementing Portals with a complete new development, infrastructure and working environment causing a fortune to be spent on hardware, education a.s.o. There' s no real asset to run SAP anymore compared with other so called plattform-suppliers like Oracle.
A great failure was also made by IT department and decision makers allowing operating departments to push every little special wish through in the original implementation project so that we' ve by now completely left standard way and - in truth - are doing indiv-development with the unpleasantness of getting support packages with the need of running SPAUs.
Of course you' re right saying that this is a matter that should be discussed by Public Sector experts as we' re dealing with processes which have their legal basis not only in out sedate civil servant staff, but also on legal foundations. And I doubt that legislators anywhere around the world are willing to pass revisions of statutes just because of SAP implementation - this in the end is a problem common to all SAP customers.
So now imagine a SAP implementation where again dozens of companies over years worked in years to implement thousands of special requirements with each company of course sending only the best-qualified and highly motivated consultants and developers it had to offer and you get an idea of where we' re standing today.
Regards,
Thomas
Hi Thomas,
You wrote: "A great failure was also made by IT department and decision makers allowing operating departments to push every little special wish through in the original implementation project"
If you are using this forum to speak philosophically, you might want to consider what would happen if an organization backed up a step to examine the effects of "jumping to the solution" rather than having done diligence of a real discovery process where a business team documents an "as is" process and identifies unnecessary services, iterations, redundancies, broken steps. It is suggested that some of the work in identifying and addressing what isnt working might not be IT related at all and certain business inefficiencies can be resolved without disruptive technological changes.
Perhaps you really touch upon the "nerve" of what those now engaged in Business Process Analysis, Modeling, Design and Implementation are striving to avoid: namely having IT "jump to the technology or product" without having a clear enough strategy, architecture, uniform data management approach and above all, business knowledge in place. This includes knowing your resources: business resources, end users as well as developers and consultants. I think Barry alludes to this when he said: "alot may depend on the landscape and what the developers feel comfortable using" and "The answer is to change the process and not the system"
As landscapes become ever increasingly more complex and requirements more demanding this isnt a luxury but a necessity. Accurately assessing requirements and current process inefficiencies and engaging people with in-depth knowledge of their business and the tasks they perform is essential. I dont hear one mention of that in your description, so the assumption would be that those steps werent taken with the full buy-in of both sides: business and IT.
One must question then what happens when the interview/discovery/interrogation step is by-passed. Does it lead to repaving with new technology without adequate assessment and design? Should we be finding fault with the tools and construction, or should we be more closely examining the blueprint or even the necessity to use the tools and make the changes?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.