Comment On Purchasing Enterprise Examiner

Managing a long supply chain involves keeping thousands of moving parts in lock-step. From purchasing to order management, demand planning to operations, even the smallest hiccup in the chain can have massive impacts. [expand full text]
« PrevPage 1 | Page 2Next »

Re: Purchasing Enterprise Examiner

2013-02-07 08:07 • by QJo (unregistered)
Another wee problem ...

Re: Purchasing Enterprise Examiner

2013-02-07 08:07 • by snoofle
...because double manual entry without reconciliation fixes more problems than it creates?

Re: Purchasing Enterprise Examiner

2013-02-07 08:08 • by Matt Westwood
Well hurry up in there for fuck's sake, I'm desperate ... to see my reports ...

Re: Purchasing Enterprise Examiner

2013-02-07 08:10 • by snoofle
Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.

Re: Purchasing Enterprise Examiner

2013-02-07 08:10 • by George Fitch (unregistered)
Let me guess... the real WTF is Microsoft Access?

Re: Purchasing Enterprise Examiner

2013-02-07 08:11 • by Raedwald
Integration in the database layer often means trying to reconcile keys with no natural relationship


Sounds better if you imagine this being spoken like a voice over from Burn Notice.

Re: Purchasing Enterprise Examiner

2013-02-07 08:17 • by danskal
It's not often that you see a system/problem that is crying out for a buzzword solution, but this web of satan is rolling around in a sweaty fever, screaming "GIVE ME SOME SOA.... please, please, just a little bit of that ESB"

Re: Purchasing Enterprise Examiner

2013-02-07 08:23 • by RuBen (unregistered)
"So why did you use SQL2008?"

"Well it was a tip from our auditor. He was helping out the president's sick daughter."

Re: Purchasing Enterprise Examiner

2013-02-07 08:26 • by Sahir Siddiqui (unregistered)
Oh yes the well known double entry technique to keep our new systems in sync, when the old systems they replaced never had any issues staying synced. Why am I not surprised.

Re: Purchasing Enterprise Examiner

2013-02-07 08:36 • by CleanCode (unregistered)
TRWTF is no mention of a database architect, or any technical people between a VP and the poor IT guy.

Re: Purchasing Enterprise Examiner

2013-02-07 08:48 • by DogsBody (unregistered)
400824 in reply to 400817
snoofle:
Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.


I've had users complain when data was fixed as it broke their workarounds!

Re: Purchasing Enterprise Examiner

2013-02-07 08:50 • by Mathias (unregistered)
I would love to read a Confession article from Remy.

Re: Purchasing Enterprise Examiner

2013-02-07 08:55 • by Tony (unregistered)
I've fonud a problem!

Re: Purchasing Enterprise Examiner

2013-02-07 09:02 • by Pock Suppet (unregistered)
400827 in reply to 400824
DogsBody:
snoofle:
Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.


I've had users complain when data was fixed as it broke their workarounds!


This. Give me the friggin report now! No need for accuracy! No one actually looks at those numbers in the first place! It's all about relative numbers! Just make the change I told you to!

Right until we get a client who *is* able to count past 20 and notices the report stupidity. Then it's time for a meeting where IT gets called on the carpet to explain why we "broke" things. Usually accompanied by the words "It never used to work like that!" And everyone thinks I'm crazy for never deleting emails...

Re: Purchasing Enterprise Examiner

2013-02-07 09:06 • by RFoxmich (unregistered)
SELECT * FROM PURCHASE_ORDER_STAGE_TAB WHERE VENDOR = 'frist';

Re: Purchasing Enterprise Examiner

2013-02-07 09:06 • by I heard it on the modem like (unregistered)
Sounds like a case of the FKIA report going way too far. http://www.centerpointforleaders.org/newsletters/FKIAReport.pdf

CAPTCHA: nulla - When the moon hits the eye of a coder in the sky, that's a nulla.

Re: Purchasing Enterprise Examiner

2013-02-07 09:08 • by Nagesh
The VP looks like he had some sense.

Re: Purchasing Enterprise Examiner

2013-02-07 09:14 • by Confessor (unregistered)
I've been party to a system like this. Some Pointy-haired-boss (or customer) gets a wild idea that they want feature XYZZY or whatever buzzword is in vouge right now. Sit down and lay out a plan for the development strategy, requirements, development effort to develop said feature. Get told that's too much time by 2 orders of magnitude. Get handed some half baked piece of software (along with half baked expamples) and get told to integrate the solution. Still takes over half the time to get a moderately working solution. Get told to ship what we have (even though it's not done) with promises that we'll come back to finish it in a few months, but never do.

CAPTCHA: I vink therefore i ven i am

Re: Purchasing Enterprise Examiner

2013-02-07 09:23 • by renewest
Lost in translation...

Re: Purchasing Enterprise Examiner

2013-02-07 09:26 • by John (unregistered)
"BizTalk doesn’t have a native connector for SQL2000 databases"

Incorrect statement

Re: Purchasing Enterprise Examiner

2013-02-07 09:26 • by RobFreundlich
400836 in reply to 400819
Raedwald:
Integration in the database layer often means trying to reconcile keys with no natural relationship

Sounds better if you imagine this being spoken like a voice over from Burn Notice.

Whaddya think, Mikey? Send Fi and Jesse to take a closer look at Purchize while you and I get some answers from the Oracle admin? Easy Peasy! But let's make it snappy - I've got plans with my ladyfriend this evening.

Re: Purchasing Enterprise Examiner

2013-02-07 09:35 • by emaNrouY-Here (unregistered)
400838 in reply to 400828
RFoxmich:
SELECT * FROM PURCHASE_ORDER_STAGE_TAB WHERE VENDOR = 'frist';


I found a bug... let me fix that for you!
SELECT * FROM PURCHASE_ORDER_STAGE_TAB; WHERE VENDOR = 'frist';

Re: Purchasing Enterprise Examiner

2013-02-07 09:38 • by Anonymous Coward (unregistered)
400839 in reply to 400826
And I need remember to wear an athletic cup if I ever meet him.

Re: Purchasing Enterprise Examiner

2013-02-07 09:39 • by Richard (unregistered)
Sounds like a good fix to me, actually. If the new system is causing a double-entry situation then it should be fixed - but that's far FAR better than having a poorly written fix that causes production data to be deleted. Not so WTF. I mean the environment is, but the VP made exactly the right call.

Re: Purchasing Enterprise Examiner

2013-02-07 09:45 • by Swedish tard (unregistered)
400841 in reply to 400838
emaNrouY-Here:
RFoxmich:
SELECT * FROM PURCHASE_ORDER_STAGE_TAB WHERE VENDOR = 'frist';


I found a bug... let me fix that for you!
SELECT * FROM PURCHASE_ORDER_STAGE_TAB; WHERE VENDOR = 'frist';


And I've got a fix too...
STAB STAB STAB STAB_STAB_STAB_STAB STAB STAB 'stab';

Re: Purchasing Enterprise Examiner

2013-02-07 09:51 • by golddog (unregistered)
400842 in reply to 400823
CleanCode:
TRWTF is no mention of a database architect, or any technical people between a VP and the poor IT guy.


Let's not suggest that is necessarily the solution.

I overheard our recently-hired DBA/Data Architect talking with someone, explaining how to generate a script out of a database on SQL Server.

"When you save the script, make sure to save it as ANSI, not Unicode. When you save as Unicode and check it into a repository, that messes up the file."

I remain unimpressed.

While I don't like the Captcha repeating meme, I find it sadly ironic that it's "genitus" for this post. Which might describe our DBA: not quite a genius.

Re: Purchasing Enterprise Examiner

2013-02-07 10:23 • by Rich L. (unregistered)
Definitely one of my favourite WTF's of all time (up there with my friend the Shredder).

Thanks for sharing.

Re: Purchasing Enterprise Examiner

2013-02-07 10:34 • by DrPepper
[So, all of these other systems stopped merely dumping data into the Examiner, and started extracting data too.]

An ad-hoc reporting system morphs into a "source of truth". There should have been about a hundred DBAs who choked on that idea; their role is the protection of the integrity of their data at all costs.

Allowing data to flow back into one of their systems from an untrusted source should have raised red flags up the chain. And should have resulted in the firing of the people who allowed the data to get so screwed up.

Re: Purchasing Enterprise Examiner

2013-02-07 10:38 • by Dave (unregistered)
The whole time I was expecting the article to end with some moral about not having P.E.E. (Purchasing Enterprise Examiner) in your pool (of data solutions).

Re: Purchasing Enterprise Examiner

2013-02-07 10:56 • by HowItWorks (unregistered)
400847 in reply to 400845
Dave:
The whole time I was expecting the article to end with some moral about not having P.E.E. (Purchasing Enterprise Examiner) in your pool (of data solutions).

TRWTF appears to be refering to Examiner, rather than using the acronym.

Re: Purchasing Enterprise Examiner

2013-02-07 10:59 • by Another Anon (unregistered)
Any chance of trying to reorganize Payroll through this Oracle system? At least trial it out with the numb-nuts' own account information?

Re: Purchasing Enterprise Examiner

2013-02-07 11:20 • by miker (unregistered)
400849 in reply to 400842
[quote user="golddog"][quote user="CleanCode"]
"When you save the script, make sure to save it as ANSI, not Unicode. When you save as Unicode and check it into a repository, that messes up the file."

I remain unimpressed.[/quote]

Really good advice, assuming he is not referring to UTF-8.

A lot of tools will treat UTF-16, or UCS-2, files as binary. I can't remember which one SQL Server spits out by default, they are both bad UCS-2 is worse.

I use an export tool that converts everything to UTF-8, but ASCII would be good enough for me.

Re: Purchasing Enterprise Examiner

2013-02-07 11:33 • by Nagesh
400850 in reply to 400842
golddog:
CleanCode:
TRWTF is no mention of a database architect, or any technical people between a VP and the poor IT guy.


Let's not suggest that is necessarily the solution.

I overheard our recently-hired DBA/Data Architect talking with someone, explaining how to generate a script out of a database on SQL Server.

"When you save the script, make sure to save it as ANSI, not Unicode. When you save as Unicode and check it into a repository, that messes up the file."

I remain unimpressed.

While I don't like the Captcha repeating meme, I find it sadly ironic that it's "genitus" for this post. Which might describe our DBA: not quite a genius.


Windows not support unicode complete like unix and linux.
I could find severe links to this statement, but I can't bother to google right now.

Re: Purchasing Enterprise Examiner

2013-02-07 11:43 • by C-Derb (unregistered)
400853 in reply to 400826
Tony:
I've fonud a problem!

was it this?
remy:
He traced the tendrils of data back to the other systems, and fonud nothing amiss

this?
remy:
So we use SQL2008 to proxy your data and pump records too and from Purchize.

or this?
remy:
... told the users that they simply had to keep manually enter their changes in both Purchize and Oracle.

Re: Purchasing Enterprise Examiner

2013-02-07 11:48 • by Foo (unregistered)
400855 in reply to 400815
snoofle:
...because double manual entry without reconciliation fixes more problems than it creates?


without reconciliation, you'll never know what problems it creates, so yes.

Re: Purchasing Enterprise Examiner

2013-02-07 11:53 • by snoofle
400856 in reply to 400845
Dave:
The whole time I was expecting the article to end with some moral about not having P.E.E. (Purchasing Enterprise Examiner) in your pool (of data solutions).

A pool of PEE? This is becoming a theme!

Re: Purchasing Enterprise Examiner

2013-02-07 11:54 • by cellocgw
<quote>Managing a long supply chain involves keeping thousands of moving parts in lock-step. From purchasing to order management, demand planning to operations, even the smallest hiccup in the chain can have massive impacts.</quote>
There's the WTF in a nutshell. If your production system is not fault-tolerant, you're doomed no matter what.

Re: Purchasing Enterprise Examiner

2013-02-07 11:58 • by cellocgw
400858 in reply to 400819
Raedwald:
Integration in the database layer often means trying to reconcile keys with no natural relationship


Sounds better if you imagine this being spoken like a voice over from Burn Notice.


+1 for that. I'd give you more points, but apparently that's frowned upon in these Web2.x days.

Re: Purchasing Enterprise Examiner

2013-02-07 12:05 • by UK Pete (unregistered)
400859 in reply to 400827
Pock Suppet:
DogsBody:
snoofle:
Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.


I've had users complain when data was fixed as it broke their workarounds!


This. Give me the friggin report now! No need for accuracy! No one actually looks at those numbers in the first place! It's all about relative numbers! Just make the change I told you to!

Right until we get a client who *is* able to count past 20 and notices the report stupidity. Then it's time for a meeting where IT gets called on the carpet to explain why we "broke" things.


This wasn't a UK bank by any chance?

Re: Purchasing Enterprise Examiner

2013-02-07 12:20 • by Lerch98 (unregistered)
The technical term for this is Cluster Fuck

Re: Purchasing Enterprise Examiner

2013-02-07 12:28 • by Shoreline
400861 in reply to 400827
Pock Suppet:
DogsBody:
snoofle:
Interestingly, our users only care about getting their reports. Yet they've never complained about all the broken data on which they're based.


I've had users complain when data was fixed as it broke their workarounds!


This. Give me the friggin report now! No need for accuracy! No one actually looks at those numbers in the first place! It's all about relative numbers! Just make the change I told you to!

Right until we get a client who *is* able to count past 20 and notices the report stupidity. Then it's time for a meeting where IT gets called on the carpet to explain why we "broke" things. Usually accompanied by the words "It never used to work like that!" And everyone thinks I'm crazy for never deleting emails...


Same.
"How come you never delete emails?"
"Leverage."

A colleague of mine who wrote the reports was told one of his reports was "always wrong" based on the fact that two completely different numbers in the report were different.

Re: Purchasing Enterprise Examiner

2013-02-07 12:32 • by chubertdev
Remy, time to update your schedule:

1) caffeine
2) author article
3) more caffeine
4) proofread article
5) ?
6) profit

Re: Purchasing Enterprise Examiner

2013-02-07 12:38 • by James (unregistered)
The True WTF is the usual bizTalk solutions I see deployed. I am amazed at the number of folks out there who really think a COTS middle-ware layer is going to solve their problems.

I suppose its a nice short cut for some situations; but really message routing, and workflow is the easy part of most middle-ware efforts. If you don't have a decent bench of systems people and developers its gonna be FAIL.

Add to the problem that for some reason almost everyone who has ever built an orchestration in BizTalk thinks this somehow makes them Gods gift to the field systems integration. Weird culture issue there. Especially when they all run around designing things like in today's article. Seriously using a SQL2008 instance as proxy server? Really? Someone decided to go to production with that?

Honest on the best BizTalk project outcomes I have saw was an organization where after a year long attempt to get their Commerce Server based website to put orders into their GL and fulfillment systems successfully, wound up with this:

BT ( using the same database engine the site was on incidentally ) would pickup XML orders written out by the site to a directory on a file system, it would format them as more human targeted text then e-mail them to a customer service rep. The customer service rep would then manually enter the order, into both the accounting/GL systems and various fulfillment suff; which includes some sort of technician scheduling application, and creating receiving and picking tickets for the warehouse staff. Then if everything was okay, credit card accepted (yes the numbers were mailed to the CSR, but TLS was used so its okay right? ) the CSR would reply to the Biztalk e-mail adding the PO number to the subject. Biztalk would then do a few database look-ups get the final shipping cost ( rather than the badly estimated on made on line at order time), and build a recipient/confirmation all as a giant XML blob and drop it off in a file folder for Commerce Server to read at some point and wait for it: format it as a more human target message and mail it as the order confirmation....

Re: Purchasing Enterprise Examiner

2013-02-07 12:49 • by Evan (unregistered)
400864 in reply to 400850
Nagesh:
Windows not support unicode complete like unix and linux.
I could find severe links to this statement, but I can't bother to google right now.
Hahahahahahahahaha

Re: Purchasing Enterprise Examiner

2013-02-07 12:54 • by Michael Bolton (unregistered)
This has been my job for the last 7 years.
Yee ha.

Re: Purchasing Enterprise Examiner

2013-02-07 13:05 • by john (unregistered)
Better than the solution I expected to hear from the VP: "just use a shared spreadsheet".

Re: Purchasing Enterprise Examiner

2013-02-07 13:23 • by Remy Porter
400869 in reply to 400853
I actually added fonud to my spellchecker, just to toy with you all.

Re: Purchasing Enterprise Examiner

2013-02-07 13:53 • by iMortalitySX (unregistered)
I think there is always a WTF if you draw a chicken and call it a data flow. Seriously though, am I the only one that sees a chicken in the drawing?

CAPTCHA: vindico; Latin for avenge, punish, liberate, deliver, protect. I have seen chickens do none of these.

Re: Purchasing Enterprise Examiner

2013-02-07 13:56 • by J (unregistered)
...and told the users that they simply had to keep manually enter their changes in both Purchize and Oracle.

Wanted: Data Entry Clerk
Requirements: PL/SQL programming experience

Re: Purchasing Enterprise Examiner

2013-02-07 13:58 • by Michael (unregistered)
This is simply the status-quo most places I have worked. I agree that it's broken and messed up, but hardly a WTF.
« PrevPage 1 | Page 2Next »

Add Comment