About Me

Hi,

I'm Suren, I have had the opportunity to work with 3 ERP Solutions as a Project Manager / Consultant/ Executive and in this BLOG I'd like to share with everyone, my experience in implementing these ERPs.

I believe that to learn and understand an ERP you need to first look at it, at a conceptual level, once you have that part of it sorted the details are much easier to grasp. Most importantly, you need to have that knack to make things happen, a good ERP System probably has many best-in-class processes already built into it, its up to the intellectual ability of the consultant to adopt these or perhaps even alter them a bit to best suit the clients requirements, and oh yeah, smile when you do so, soft skills coupled with technical skills is what makes a consultant tick !!

Hope you find my blog enjoyable and informative.

Any comments, ideas, suggestions and questions, either regarding the industry or anything related to the blog posts are all welcome, you can contact me on :

Email : ssurenlk@msn.com

Skype : ssuren_skype

MSN Messenger : ssurenlk@msn.com

Disclaimer

The articles on this website are 100 % my own work based on my research finding, unless otherwise stated. The views expressed are my own and not of anyone else.Using this information is at the users own discretion and responsibility.

ERPs I have worked with :

SAP R/3 – FI/CO, PP

IFS Applications – Financials / Distribution / Business Intelligence

SAGE ACCPAC– SM, GL, AP, AR, IC, OE, PO

Peresoft Cashbook - V5.0

When ERPs get the taste of SOA !!!

Well then, whats SOA then and what is in it for us (ERP Provider) if we are to follow this architecture.

In my previous post, I have already quoted Mr.Hao He who had a wonderful article on what SOA is all about.

Today, I will be going into some detail on how ERP Providers around the world are looking to change their models and methodologies to fit in with SOA.

Starting up lets look at IFS, with a component based architecture in its armor from 1994 it has been among the pioneers in introducing a component based approach in providing a business solution. With the addition of SOA, IFS has taken the concept to the next level with the SOCA (Service-oriented compoenent based architecture) model.

This model not only uses the service oriented approach to architecture but with the inclusion of components makes it even more flexible and loosely coupled which by the way are the pre-requisites for SOA.

With this mix….it makes it possible to design business solution that integrates a collection of services or groups of components that perform business processes. With the primary objective being able to deliver platform independence and not being tied to a specific technology.

Since IFS has had component based architecture since 1994, the shift IFS has had to make to cater to the SOA concept is almost imperceptible and readily locks in with the component based style of delivering the end users business needs.

There are many more advantages of providing a component based model especially for business solutions, only a few of which I will just list down now, as this is not the core area I am looking to explain in this article.

Benefit from a component-based application

l Step-by-step

l Agility

l Open interfaces

l Efficient development

Now let’s look at another ERP Provider, SAP. SAP has begun planning for its vision of SOA, with its releases of narrowly defined models or packages which are based on its NetWeaver development and integration platform. Previously, they released large-scale updates of closely interlinked components and then later setup about defining the configuration of the necessary modules that would serve the business needs of the end users.

However, now with the provision of business models, SAP provides the ability to setup the system up and running quickly, still assuming that the particular business model supports the relevant business needs.If this is not the case, then the appropriate models will also need to be setup and then configured accordingly.

Now, getting back to NetWeaver, this service based platform comprises several technologies and components: a portal framework, business intelligence and reporting, Business Process Management (BPM), integration, Master Data Management (MDM), a common run-time application server, and the SAP application development and management platform.

Using this platform SAP is looking to make tune its architecture into a more SOA based style, however we should understand that given that a componentalised framework is a pre-requisite of SOA, its still got a few touch up work to be done on its business models, packages and sub-business models.

Given SAP’s increased interest in penetrating the small and medium enterprise (SME) market, its approach of providing process models ready for deployment makes a lot of sense and is something that will definitely be looked at closely by many industry analysts and competitors likely, and I, not being any exception.

Now, let’s turn our attention to one ERP Provider who are eating their chunk of the market by literally eating up other smaller ERP Providers, yes its ORACLE.

Oracle, calls it Project Fusion, this is there contribution to the developing a system that falls in line with the SOA concept, what they intend to do is provide a set of tools that will assist in modeling the business process as per the end users requirement. This would help in delivering components tailored to the end users environment. Interestingly this provides the ability to be more adaptable which is what large companies have learnt from smaller ones, so to say, and what they intend to do to be more successful in their business processes.

So the future looks promising for the SOA model, and I shall try my best to keep updating this blog with the other changes that come about.

Best Regards

S.Suren

Consultant

Some of the above contents were extracted from Joseph J. Strub’s article, and were modified to reflect my ideas taking into account other related information.

Ever thought of Project Management as a service?

Books teach you what u should and should not do, experience teaches you what is best way to do what you should do and should not do !!!

Remember, the right attitude is very important if you work in the service industry, like the old saying goes.... "Ability is what you are capable of doing....Motivation is what determines you to do it.........Attitude determines how well you do it"

Now talking about service have you ever thought of Project Management as a service?

How many of the projects that you know have been completed on time ? I know quite a few. How many of these projects have actually ended with the customer smiling and handing over to you the project completion form? The simple reason is that the customer was not happy with the way you delivered the outcome, maybe you did deliver a wonderful solution and the final outcome was excellent but then why was the customer not happy ?

It is more about the way you did it rather than what you did!!


The reality is that with the dynamic environment that surrounds today’s IT driven industries very few IT professionals even have the time to draw up new deadlines when the previous ones are not met, let alone the need to practice properly customer service management during the project itself.

The first thought that would pop up when we say the word project management is…..managing resources to perform an activity. Managing these resources is more than just using them cost efficiently, it also refers to using them effectively.

To use these resources effectively we need to first judge how effective they can be and how effective they are likely to be given the conditions they are going to work in.What then is these resources, is it the people, the capital, the materials etc etc?Well, the resources are nothing else other than what you have to work with.

Therefore, it is simply the elements in your working environment. Most of these resources are the same ones that are used in the service industry so why then can’t these resources be used in a project as a service element as well.Let’s now see how we can practice service functions in a project:Communication is one of the key ingredients in any project, this is what determines how well the project progresses and how well the outcome suits the requirements of the customer. Here we will be seeing how communication helps providing a better service during a project.


Your Late !!!


How many times have to you been late to a meeting? It is understood that there can be unforeseen circumstances that could have delayed you but was this communicated to the customer. If so, good, but how was it, done?

Did you inform the customer about the reason you were late after arriving at the premises or was it while you were on your way?If you did the first one, ie. To inform the customer after you had reached your destination, it is not going to make a big difference to how your customer feels. He is already upset about you being late and now a reason to justify this after the damage has been done is not going to smoothen off things.

If you informed the customer during the delay period, the customer would feel better since he knows what your position is and he will be glad that you called him and gave him the space to do other things that he might have to do until your arrival. The tone and words you use during this situation is very.


Hello, are you done?

How many times have your customers called you inquiring on the progress of an issue that you said you would report to them?Most probably many times. It is understandable that it can be hard sometimes to follow up on each and every issue when involved with many other things in the project, but, this small instance of the customer calling you would make him to think that you would not do it unless being reminded about it.This happening regularly would reduce the customer’s confidence in you and eventually affect your companys relationship with the customer.

The simple solution to this is to make a note somewhere that will remind you of this customer’s request, whenever you see this note just call the customer and inform him something about the status of the issue even if you haven’t actually started at it yet (anyhow make sure you have allocated time to atleast look into it !!). Doing this for one, would put the customer at ease because for him he would have least expected the call and to receive it when he is in the middle of his work would communicate to him that there is someone else at that particular time who is looking into his requirement.


This practice normally gives you that additional time to complete the work since the customer would understand that you are looking at it seriously. While working on the issue, it is best to call the customer and just confirm something about the requirement, this will have a positive impact.

What an opportunity?

They say that every unsatisfied customer says his experience to 11 others of who 5 say that to another 11 and this continues. By taking time to satisfy that one customer you are saving on a lot of unnecessary reputation loss.Has your customer ever jumped at you the moment you stepped into his office about your service, though he hasn’t met you anywhere before? Well I have had that experience, may be he was not satisfied with your company’s overall customer service, and he takes it on you since he knows that you are from that company.

If this is the case, it is like striking GOLD. Because the customer has never worked with you personally before and he would be expecting the same service from you too, but if you can calm him down and make sure that you look into his requirement seriously and keep him satisfied, this is going to be one happy customer.

Take time for this customer; look into what he is upset about, start work on it. Keep touch with him regularly, until the job is done. It is understood that the customer might then be more demanding since he would be under the impression that he needs to yell at you to get things done, let him know that this is not the case.


For instance. When you have completed a single task call the customer and let him know, he would atleast say “Thank You” when he does you let him know that the task was easier because of his active involvement (reverse psychology I suppose). Once you have completed the task fully, just let the customer know how resources from other projects were taken to handle this task and how other customers supported this.

He would appreciate this and the next time he calls you he knows that you would do your best and he would be nicer this time.

And there you are (11 + 5 + 11 + 5…..) this many customers will not have the chance to hear about your unsatisfied customer simply because you don’t have one now.


More soon…..

Daffy : Which way did it go Buggy...... Which way did it go !!!

Bugs Bunny : The ERP went thatta way !!!


Well, what then are we talking about above...its nothin else than which way the ERP Architecture is headed. After all the debate and hype on developing ERPs on a solid platform that will support it being ever so flexible and easy to integrate with just about any other software, here comes a new term talking about the exact same thing but with a new outfit, attracting all ERP Vendors to follow it to the end of the previous world of thinking ....


So whats this term ??? Yeah, you guessed it...and if you didnt get to know it now ;-).......its SOA (Service Oriented Architecture).

Courtesy : Hao He

Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.

The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one.

The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:

1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

As illustrated in the power adapter example, interfacing is fundamentally important. If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications.

Since we have only a few generic interfaces available, we must express application-specific semantics in messages. We can send any kind of message over our interfaces, but there are a few rules to follow before we can say that an architecture is service oriented.

First, the messages must be descriptive, rather than instructive, because the service provider is responsible for solving the problem. This is like going to a restaurant: you tell your waiter what you would like to order and your preferences but you don't tell their cook how to cook your dish step by step.

Second, service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility.

Third, extensibility is vitally important. It is not difficult to understand why. The world is an ever-changing place and so is any environment in which a software system lives. Those changes demand corresponding changes in the software system, service consumers, providers, and the messages they exchange. If messages are not extensible, consumers and providers will be locked into one particular version of a service. Despite the importance of extensibility, it has been traditionally overlooked. At best, it was regarded simply as a good practice rather than something fundamental. Restriction and extensibility are deeply entwined. You need both, and increasing one comes at the expense of reducing the other. The trick is to have a right balance.

Fourth, an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry.