Friday, December 17, 2004

Message from Cheng-Jay and Reply

ChengJay,
There is an abundance of research on ERP success. Mainly the titles or the document bodies include "ERP success factors, ERP risk factors" etc. so you can use those as keywords. I used to use ERP success as keywords to find these. Once you find a good research article, you can look at the references of that article to find more articles.

Some good researchers you will run into are Lyman Markus, Dianne Strong, Olga Volkoff, etc.

Also look at AIS conferences such as AMCIS, ICIS, etc. AMCIS had an Enterprise Resource Planning track a few years back. Now it has a Enterprise Systems track/sig.
So you can look at the conference proceedings to read them. When you become AIS member, you can get the conference proceedings online for free.

Let me know if this helps. I will try to send you some articles soon but keep on doing searches on the databases. make sure you use the right databases. I use proquest a lot. Also google has a new scholarly search engine: scholar.google.com

Yeliz. (yeliz2002@gmail.com)


ChengJay said...

Dear Eseryel :

I'm a postgraduate student of NCU in Taiwann.
Researching in ERP systems performance
evaluation is undergoing. But now, I have some
problem in finding the research about the ERPs
success model and performance measurement.Most
of such researchs are hard to find in the
database from many journals. Can you do me some
favor? Or, You can give some advice about doing
ERP performance research.

I glad to visit your blog site and have chance
to make qcquaintance with you. By the way, I had
try to contact with you by the email you put on
your blog. For some reason, the email can not be
delivered successfully.

Maybe you can contact with my through email of
mine. My email address: 92423019@cc.ncu.edu.tw

Best regard!!

Cheng-Jay Wu
Department of Information Management
National Central University

Friday, December 10, 2004

Qualitative Research Resources (Click here)

Has a blurb on validity and reliability of qualitative research too.
Yeliz.

Sunday, December 05, 2004

Repertory Grid Technique

Alban-Metcalf, R. J. (1997). Repertory Grid Technique. Educational Research, Methodology, and Measurement: An International Handbook. J. P. Keeves. New York, USA, Pergamon: 315-318.

WHAT IS REPERTORY GRID TECHNIQUE
It is a reserach methodology, an approach to understand how people view the world. The idea is that people identify each element with a finite number of constructs and for each construct they have two poles in their mind.. Three steps are presented:
1) Identify the constructs individuals use
2) Understand how these constructs are utilized
3) Understand the interrelationships between the constructs

HOW TO IDENTIFY THE CONSTRUCTS
1) Interviews (show them 3 elements at a time and have the interviewees identify the differences among them
2) Interviewee can show all elements at once and ask for constructs (showing them on a grid)
3) Ask for written or oral free descriptions of each elements in third person. For example "self-characterization" grids.

Laddering up/ laddering down and pyramid construction are ways of coming up with repertory grids.

Dynamic grids (longitudinal for example) or static grids are two types of grids.

See Fansella & Bannister's 1977 book for more info.

COMMENTS ON THE TECHNIQUE
It seems like it can help me come up with the behaviors or constructs related to successful project managers.

Links for Inductive Reasoning (Inductive Logic)

Wikipedia Entry
Another source that list fallacies of Inductive Reasoning

Saturday, December 04, 2004

HOW TO COLLABORATE USING THIS BLOG

Okay, I've been telling people that I am really interested in sharing this blog.
I think the people who would like to share it should be actively thinking and researching on Enterprise Systems or Enterprise Resource Planning Systems.

I would like to use this blog to reflect on research related thoughts, and also share our latest readings, conferences, resources, etc.

I found that writing my thinking process helps me reflect and think better, as I am writing, I think of new ideas. Also I have tons of ideas and I sometimes forget about my though process or what my questions were. Then I can come back to this blog and look.

The other thing I would like to do here is to use this place to create an annotated bibliography or critically evalute the readings here.

I believe sharing this blog with each other will help us keep doing more reflective thinking. And also we will give each other feedback and ideas and motivate each other.

So if you're interested, just let me know :)
Yeliz.

Thursday, December 02, 2004

The Feedback I got on My Research Project

· SELECTION: Why 3 companies? Why manufacturing companies, etc.?
· Found a mismatch between using grounded theory approach and having a framework (although it isn't something that's not impossible this idea needs to be defended since it will be questioned!!!)
· My question is related to competencies of the project managers but my framework is project management competency areas. Thus the level of granularity isn't the same.
· Can I improve the theoretical framework or find a better one?
· I need to explain why Project Management for ERP is different than other types of projects. Actually Bob asked me how is it different from NASA projects. I said it is different due to the organizational change management aspect, however there is still a lot to learn and borrow from NASA type really complex projects. (Maybe the question is "Is PM for ERP really different than other projects? I am sure there are some projects out there that has similar PM requirements)
· Phases-- How do you know which phase the company is in? The boundaries of the phases aren't clear.
· Somebody suggested the Repertory Grid Technique as a research methodology. These are used in system's analysis. (Keeves' book has an article on the methodology by Alban-Metcalf)
· Interviews with other people in the company. Team lead, internal customers of the PM, IS, business department, etc
· Why are you interested in self-reported competencies?
· Why don't you use open ended surveys?
· Inductive reasoning.

Tuesday, November 30, 2004

Screwing the sampling

I am selecting cases based on the group of companies I would like to generalize the results to. That might be oversampling. Maybe competencies don't change based on the company features. Gotta find that out.

Project management Competencies

-Look at the project management literature to understand what factors affect project management competencies.
- Company size?
- Measures related to project complexity?
- Different competencies by novices and experts?

By the way, do I need to do a background survey for this and how would I build/use this survey?

Monday, November 29, 2004

Project Manager Competencies

Assumption:Project management competencies needed in various phases of ERP implementations differ. How do I know that? I just do. Experience. Logic. It just is. So if I haven't run into literature that mentions this, can I just say that it's a gap in the literature, or do I have to strive to make my point?

Sunday, November 28, 2004

Some More Thoughts About My Research

Main Research Topic Revisited
In both cases it is about "The perceived skills needed for project managers for doing their jobs" Because there isn't much literature on what type of skills are needed for successful project managers. So I believe that perceived skills needed would be a good starting point. Then a future study would be based on linking those skills with organizational success. The reason why I am not attacking the question "project management skills needed to for ERP success" is because measuring success is very difficult when I have a meaningful definition for success.

Actually maybe it is not. I want to define ERP project success as;
1- Project completed on time. (The challenge is to identify whether a project is on time when the project scope is changed over time)
2- Project completed on budget. (Similarly budget may change over time)
3- Project quality (as some call it) or Customer Satisfaction or Project goals of return on investment, customer satisfaction, employee satisfaction, etc are achieved. (The problem with this is that the business must have initially identified the goals of the project as well as the timeline to achieve the goal. For example: employee reduction of 10% within 5 years, or Increase in Sales of 17% within 3 years after the implementation. If the goal isn't specified numerically and the timeline isn't mentioned, than at any point in time, it is impossible to identify whether a project is successful or not)
Okay, writing it down again changed my mind again. Yes, measuring success is difficult!!!

Options for Research Focus:
1- Look at project management skills before go-live and after go live, see how they change.
2- Just evaluate which skills are needed after go-live.
-This will be different based on the approach they chose: big bang implementation(implement all modules at the same time), phased implementation (one module at a time) or mini bing bang implementation (implement multiple modules at the same time but not all)
-Also whether some implementation is going on now (if they have chosen phased or mini big-bang implementations)
-How long it has been after go-live is also important.

What I Need To Do Research On:
1- Project management success in IT implementations- How is it measured.
2- How is ERP success defined/measured in ERP/ES studies.
3- Do Research On Case Study Method. (Order Yin's and Stake's Books)
4- Read on Grounded Theory (Glaser's books)
5- Research on definitions of ERP Success, ERP Implementation Success , and ERP Project Management Success. How are they different? How can we define and measure them seperately?

Saturday, November 27, 2004

Positivist or Interpretivist approach?

Research Question:
I am trying to understand the Project management success factors in the maintenance (or after go-live) phase of the ERP implementation.

Philosophical Approach:
I am still having trouble about selecting the right approach for my ERP study. Looks like Markus et. al. is totally against an interpretivist approach in evaluating ERP success in their article called "Learning from Adopters' Experiences with ERP: Problems Encountered and Success Achieved"

Some Issues:
Also some of the problems I am facing are related to defining and measuring ERP success.
Actually maybe defining success isn't difficult, I have a good idea about it from the literature. The problem is how to measure it really.

Another issue I am having is how to select the sample. Ideally one wants to select successful companies or companies who have project success. How to identify those is a real problem when success now isn't really a predictor of success later.

I Just Though Of Another Question:
So is project management success in ERP implementations different from ERP Success? Okay, so I need to define both project management success and ERP Success. Actually ERP success and ERP Implementation Success are different things. Geez..

Okay, regardless of the philosophical approach, let me think about the research method...Maybe, I need to have a longitudinal study. So if I take some companies and identify some success factors and project management related factors... And then measure them across time. It might work.

Okay, what is the downside of this method?
1) Well, all companies need to be still within the same phase during both measurements. Because different phases have different success factors. So if one company slips into another phase, then I will be in trouble.
2) What is really the d


Thursday, November 25, 2004

Literature Review

I am going through Gina Boff's dissertation called "Implementing an Enterprise Resource Planning System: What Differentiates the Corporations that Make it From Those That Do Not". The good thing is she made me aware of the Special Issue on: Critical Analyses of ERP Systems in the The DATABASE for Advances in Information Systems journal by D. Howcroft and D. Truex. The interesting issue is that she based her lit review on this special issue and a few other articles. She even said something along the lines of "This special issue doesn't cover ERP implementation, thus there's a gap in the literature on Implementation issues."

Wow, I don't know what else to say now. There's so much stuff out there about implementation issues, it's hard to miss.

She has a stronger methodology section though. I will keep on reading. But now I don't know what to believe and what not to believe among the things she said.

TRIANGULATION:
She said that qualitative researchers use wide variety of interpretative practices to get better understanding of the subject matter (Denzin and Lincoln, 2000) This more traditional, multi-method approach in qualitative inquiry is what is commonly referred to as Triangulation.

I thought Triangulation was something along the ways of using other resources or means to check your conclusion. I think it might be a method, it might be using literature, etc.

I asked this question to Kevin, here's his response:
"Yes, using multiple sources of evidence as a check on each other. It could be different data sources, but also different research approaches. Most people would restrict it to empirical evidence though, so not literature."

Wednesday, November 24, 2004

Maybe, its just a dream...

I was thinking about the failures inherent in Business Process Reengineering and Enterprise Resource Planning Implementations. When I was mentioning that BPR mostly failed in 90's, Romas had said "yes, because they didn't implement the technological systems that would support the change". I don't totally buy that although he has a point. I think it's more about difficulty of change, and organizational power dynamics, and difficulty (or unwillingness) of the human beings to learn and adapt quickly that cause these initiatives and others to fail.

On the other hand, Gina Boff suggests in her dissertation that companies implement ERP Systems in order to achieve competitive advantage. Think about it for a minute: How do you obtain competitive advantage by just doing something that is done by the rest of the industry?

But my main point, the a-ha moment I had, wasn't about these. I think there's an inherent copying of other businesses in order to be successful. For example Amazon or Southwest came up with a great business model, right? Why didn't their competitors, who just tried to copy their structure or technology or look failed? Because they missed something that these companeis were doing that was crucial for success. Thus it is crucial to understand ALL success elements and match them and even go beyond them by being open to changing business models, etc. I just think it's not for everybody.

So when we come to ERP implementations. Yes there were some companies who could reengineer their business processes and implement ERP and receive significant ROI. However, it's not for everyone. Some of the questions I would as are: How deep is your pocket? How flexible are your people? How forgiving are your customers?



Sunday, November 14, 2004

A Knowledge Transfer Dissertation in ERP Context

I just read a dissertation that I want to share with you.

Ko, D.-G. (2002). Determinants of Knowledge Transfer in Enterprise Resource Planning Implementation. Unpublished Dissertation, University of Pittsburgh, Pittsburgh.

Annotated Bibliography Entry:
In this study, Ko tried to identify the determinants of knowledge transfer in Enterprise Resource Planning implementation context. Ko concluded that individual characteristics such as source credibility, communication decoding competence, intrinsic motivation, along with characteristics of relationships (especially relationship quality) and knowledge observability are important predictors to the transfer of knowledge in the context of ERP implementation. Ko's model also finds that relationship quality is a mediator between the independent variables; source credibility, and communication decoding competence and the dependent variable knowledge transfer. Another significant finding is related to intrinsic versus extrinsic motivation: The study suggests that recipients must derive satisfaction in the work content itself to effectively transfer knowledge. The knowledge observability, for example ability to make a change in the system and observe it's implications in another part of the system also increase the knowledge transfer.

Future Research:
1) Improve this model of knowledge transfer among individuals.
- Task similarity appeared to influence knowledge transfer (Slaughter et al. Work in progress)
- Complexity of knowledge being transferred as well as the timing of the transfer and openness by the recipient (Argote, 1999)
- Whether geographical proximity or co-location facilitates knowledge transfer. (Epple, et al., 1996)
2) Identify factors that may determine the transfer of knowledge in the various stages of ERP implementation (Markus and Tanis 2000)
3) Examine a process model of consultant-client relationship. (Nonaka, 1994)
4) At what points do consultants leave and the implications associated with transfer of knowledge.

Tuesday, October 12, 2004

On Consultants and Employees and Change Management

From Consultant M's Blog
(http://blogs.ittoolbox.com/erp/implementations/archives/001245.asp)

ON CONSULTANTS AND EMPLOYEES AND CHANGE MANAGEMENT

A good mix of employees and external consultants is, in my view, essential for a good implementations. This project has a good balance between consultants and those knowledgeable in the business. We have a strong communication and participation with the actual user community who will be using the system once we let it loose on them. The users need to approve each step before the implementation team can proceed. This started with gapping, and continued with initial design, detailed design, etc. This will assure that nobody can come back during roll-out and say “we have never seen this” or “I have never approved this”. It is as much a safeguard for the users to ensure that they know what they are to receive in the end, but also for the implementation team and for management. Both can verify that the design had been approved by a broad user community.

The ideal balance between In-house experts and consultants depends heavily on management’s goal to re-engineer business processes, employees’ knowledge of the software system and the unique requirements of the business. By nature, each business operates differently. Most have distinctive business process that developed out of unique circumstances; many also have certain business processes that provide distinctive business advantages over its competitors. These are processes that a company should not change and where intricate knowledge is required that only in-house employees can provide. Neither of these processes will be provided by a standard software package – not even I2 or SAP.

On the other hand one needs to be open enough to allow changes in business processes to perhaps save millions in custom development. Over-development of custom processes can create a system that cannot be supported by the original software manufacturer and where software upgrades take as many resources as the original implementation. One must look at the individual software packages and examine how perhaps smaller changes in the business process could provide a compromise between the processes and the mechanism of the software and lead to major savings in time and cost of development. This is an area where general management as well as consultants can provide good inputs. Employees will always try to duplicate their old methods and procedures and, if they get the chance, will even duplicate the old Cobol or C++ screens.

Most importantly, one also needs to look at parts of the business process that are inefficient and could gain from process improvement. This may be difficult if the current employees, who also have to be convinced that the new software implementation is going to offer advantages, have to change their old ways and habits. This leads to a difficult subject of CHANGE MANAGEMENT. I have often seen a business following a methodology that was developed 20 or 30 years ago and is reluctant to adopt to the new ways. External viewpoints and experience are needed for this part of the implementation as well. (For example, a previous client was adamant about maintaining their procurement method because they knew of no other process and did not trust their consultants. This resulted in lead times twice as long as the industry average and in high inventory levels and lack of control thereof.)

Although I had said at the beginning that this project has a good mix between employees and consultants, the major issue I see is with the last point. The company is at times using business practices that seem to have carried over from pre-industrial times. The user community is not willing to look at today’s best practices approach and work towards a more streamlined and effective business management. The culprit is, I believe, the lack of a strong management leadership on the user community. It is impossible to have a good implementation and achieve long-term gains and improvements for the company as long as management is not convinced of the need for the new software and is not open to changing today’s business processes. And so, the implementation team is developing a software that is tweaked in each and every respect to match the current legacy system.

I have seen implementations where almost each and every transaction was customized or a new one created. In the end, the original software was unrecognizable. System upgrades or fixpacks that are offered by the software manufacturer can no longer be applied.

Unfortunately, this project sees a lot of “old methods”. One in particular causes me a lot of head-aches and I will spend the next blog talking about it – so watch for the next blog that will be deal with the topic “Managing suppliers”.

It is, in my view, essential to find a good balance between good or necessary practices of the “Old World” while using the chance to improve those processes that do not meet the ‘best practices’ approach. What I mean with that is that there are many parts of the business where the software needs to adapt to the business – either because of unique or cutting edge processes, because of an already efficient and effective way of doing business, or because of unique industry requirements. But there are often many other parts where the business is too lazy to change its methodologies to adapt to a more efficient (doing the right things) or effective (doing things right) method. This change, however, can only be done if you have the support of upper management driving the change internally and if you staff the implementation team with employees willing and open to change. It is much more than a simple system change, it may require changes in how the company is working with suppliers or customers.


M

Sunday, October 10, 2004

Enterprise Resource Planning (ERP) Blog

Hi All,
I am a PhD student interested in Enterprise Resource Planning Systems. I am looking for people to share this blog with me. The best way of doing research is to think about it everyday. I figured that sharing my interest with others would keep me thinking about it everyday.

It's also an opportunity to share our knowledge with each other, reflect on what we learned and create opportunities to collaborate with each other and with others.

Interested? Leave a comment here. Tell me about yourself, what you're doing what you're interested in etc.

Having said all these, I am open to also talking about relevant issues: Supply Chain Management (SCM), Customer Resource Management (CRM), SAP, etc.

Yeliz.