Duplicate Items in Item Master / data governance

<vendor>


Dear Rob .... thanks for your insights/questions (appended),

Needle in a Haystack fires off the alert for attention before any horses get
out of the barn door. The idea is to attract attention when the horse stall
field changes from "LOCKED" to "OPENED"

Data accidents accumulate cost after the bad data has had a chance to roam
around outside the barn and propagate itself into transactions, cause
inaccurate decisions, frustrate accountants, trick planning software, and
disappoint customers. Needle in a Haystack truncates the $ consequences by
alerting the business process owner best prepared to diagnose and immediately
fix the mistake. That breaks the "gotta call IT to clean up the collateral
damage" paradigm.

Think of it like auto insurance for System i data accidents: can't prevent
them ... but ... it's a comfort to know the consequences of a fender bender
will be modest.

An ERP LX user told us on Friday that Needle in a Haystack's real-time
ability to find/yell about blank entry accidents is a better idea than
modifying source code to protect against that. (At least she had the source
code.) Here's another real-life illustration:
www.unbeatenpath.com/software/needle/iSeries-eg1.pdf

Cornell University research contributions shall expand the scope of rare
events Needle looks for using self-taught artificial intelligence, not human
configuration savvy. Expensive GRC products rely on man-months of senior
analyst effort to anticipate / configure all the things that could go wrong.
Problem is that the next dozen errors elude the analyst's imagination. Needle
in a Haystack catches accidents analysts and triggers don't anticipate.

Peace, Milt
Unbeaten Path
(888) 874-8008
+262-681-3151



</vendor>





From: rob@xxxxxxxxx
Sent: Thursday, September 29, 2011 8:23 AM
Subject: Re: Duplicate Items in Item Master (and other data accidents)

Work created by "things to check" is a valid concern. Afterwards is about as
useful as a key-to-diskette edit report. Too much to check and the emails
get added to a folder that only gets checked once a month.

But some notification may be useful. Like the customer that requested remote
access to order entry back in the days of modems and whatnot. A little
confusion on how to enter a number and you end up with 100 times more product
than what you requested. Not only did the extra product remain on the semi
but the terminal and modem got added. But then you get into the detail of
the range for this product for this particular customer should be between x
and y. Or you analyze past history. That's a lot of setup work.

Rob Berendt





From: rob@xxxxxxxxx
Sent: Thursday, September 29, 2011 8:38 AM
Subject: Duplicate Items in Item Master (and other data accidents)

<snip>
but finding the "guilty" party after the fact doesn't erase the accident
cost, it doesn't permanently slam the back doors, and it doesn't train
employees to keypunch flawlessly. There will always be the next data
accident.
</snip>

After is after is after. Your product still alerts the farmer after the
horses escaped the barn. It doesn't lock the door. To do that you would
have to add constraints to the database. And triggers for more involved
situations. The problem with that is, if you throw a write error out because
of a violation would Infor's code be able to handle that? For example would
this code:
C WRITE(E) IPI100IM
C*
C IF NOT %ERROR AND OPERRFLAG=*BLANKS
C Z-ADD 1 S_IIML02
C EXSR SMVTOW
C ELSE
C END
C ENDSR
say "dude, there's a constraint violation"?

Let's use another example. The OP asked about duplicate records. Would your
solution catch that? For example I add a duplicate key outside of Infor.
Would the DBA then get notified? Or is the product more focused on
individual field errors, like ranges and what not?

Rob Berendt
Group Dekko






From: "Milt Habeck" <mhabeck@xxxxxxxxxx>
To: "BPCS user group"
Date: 09/29/2011 08:10 AM
Subject: Duplicate Items in Item Master (and other data accidents)

<vendor>

Scenarios from Rob + Al explain how duplicate records can arrive in iSeries
files. Back doors like that also enable field-level data accidents to elude
layers of protection. IMHO, if you could add up the cost of data accident
chaos, the result would be stratospheric. Companies don't measure it. "Data
accident expense" doesn't appear as a separate line on the P+L statement.

Rob suggests journaling as a post-accident investigative tool .... and, With
effort, it works for that purpose ... but finding the "guilty" party after
the fact doesn't erase the accident cost, it doesn't permanently slam the
back doors, and it doesn't train employees to keypunch flawlessly. There will
always be the next data accident.

Here's a new idea: Needle in a Haystack software identifies data accidents as
they are written to an iSeries file and then immediately emails an alert. The
software is a real-time rare event detector which employs artificial
intelligence to figure out what is normal and what isn't ... right down to
the field level.

www.unbeatenpath.com/software/needle/in-a-haystack.pdf

It works. Real-life example: a unit of measure field was changed. The
replacement value was exponentially incorrect. Edit checking didn't stop it
(both the pre-change and post-change values were legitimate). Needle in a
Haystack immediately reported the change as a rare event, enabling the
database guardian to fix it before the next MRP run.

Needle in a Haystack's self-taught ability to identify and report data
accidents in real time is unique. Ivy League professors at Cornell University
are so impressed with the creativity and distinctiveness of the product that
they're launching research efforts to help us polish the software:
www.unbeatenpath.com/news/Cornell-Sept2011.pdf

Warm regards,
Milt Habeck
Unbeaten Path International
(888) 874-8008
+262-681-3151


</vendor>