• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Internal Support Requirements

Leroy

Active Member
We are in the process of going live with OneWorld Xe. We are primarily a distribution company with about 150 users. We are deploying Finance/Sales/Advanced Warehousing/Procurement.

The project team is made up of predominately business people who have been working with consultants doing process workshops and system configuration. The business users are 1 Finance, 1 Operations/Procurement, 1 Sales, 1 IT, plus 3 or 4 consultants. These are supported by key users at crtitical times in the project.

I'm doing some crystal ball gazing into the future to determine the type of support structure we will need in place to support the business and progress the system. I'm thinking that we would need a small dedicated team made up of the Finance, Operations and IT project members which would be increased with other business people when projects require it.

How have other sites managed support in the "Live" world?

Thanks

Lee Richards
Chief Technology Officer
Blackmores

(OneWorld Xe, AS400, Windows 2000, Citrix)
 

Adrian_Chimirel

Legendary Poster
Hello Lee,

There's a very interesting page the www.JDEList.com is hosting, called Downloads.
You may find & download the "Survey of One World IS Support, Contributed by Tony St.Pierre"
For a company as yours, the general idea is to cover ALL areas of permanent required expertise:
-CNC (might be DBA, too)
-Business Analysis, and
-Development
Your upgrades may be assisted by (out-sourced) JDE people.

We would really appreciate your participation in the Survey, too.

You're very welcome

LIVE: B732.1 SP12.2, Oracle 806, FormScape 2.1
SANDBOX: Xe SP15 & Update1, Oracle 8i
RS/6000, Citrix
 

david_mallory

Well Known Member
Lee,

From our 2.5 years of experience with OW I would recommend:

CNC: You will need 2 people to keep the ship floating and handle things that
go bang, upgrades, deal with Response Line, security changes, deal with
records that do not get written, etc. If only one person, he/she will
probably drown.

Applications programmers: You will need a person who knows procurement and
warehouse, and a person who knows finance (I am assuming you are using GL,
AP, AR, FA, job cost) and sales, or some mix like that, to handle things
that go bang, research user problems, field "program X does not work" calls,
write reports in Report Writer or whatever, tell the CNC people how the
application programs work as needed, deal with Response Line, deal with
records that do not get written. With this many modules and 150 users you
may need 3 people. These people should know how the programs work in their
areas, what programs write to what files, what the screens look like, what
the records look like, how the data flows. If you do not have flow charts
for programs and files for OW for all your modules, do them.

Do you have others to support the data base, network, and user PCs?

At least one and better two lead users in each application area (GL, sales,
etc.). These people should know what programs write to what files, what the
records look like in UTB, how to run all the screens they will use, how the
programs act, be able to train other users, be able to solve simple problems
for other users.

If you have multiple locations, have at least one person in each location
who has been trained on the main programs, files, records, integrity reports
for all modules at that location.

Have an alternate report writer such as Crystal Reports.

Have a data analysis package that at least a few people can use, to
supplement UTB which is too limited, for solving problems. I use ACL.

Anticipate twice as many bugs as you would expect. Anticipate everyone will
be swamped for months with problems, even though things look pretty good in
testing.

Write your own integrity reports for each module to detect when records do
not get written. You will need them. Run them frequently. Count on records
not getting written to GL: detect that. Count on needing to poke things into
the data base.

Find other companies in your area that use OW and do an informal user group.
Somebody who did not do OW starting in the same forest you are in can be
helpful, such as "Oh, we figured that out. We do it this way. To supplement
jdelist and do it "in person"."

Before you go live, train all users in the screens they will use. Otherwise
you are dead on day 1. Have a written procedure for using all but the
simplest screens. The lead users can do these. Not fancy, just basic. To
keep operations afloat at the beginning.

Dave Mallory Denver Water
 
Top